将站点图标打包进repo

[MewX]

您的功能请求是否与问题有关？ 请描述一下。

目前图标经常因为未知原因无法加载，刷新逻辑也是全部图标重新刷新，然后个别站点抽风导致刷新失败。

好处的话主要是用户体验，可以避免看不到图标（导致的原因可以是网络/网站/ptpp）。

描述你想要的解决方案

直接把ico打包进repo。

描述您考虑过的替代方案

release的时候包含图标。

其他附加信息

我做了些实验，目前已有的站点差不多所有图标加起来是350KB （zip默认参数），我测试了111个站的图标：

~/codes/PT-Plugin-Plus/resource/sites$ cat */*.json | grep "\"icon\"" | wc -l
111

~/codes/PT-Plugin-Plus/resource/sites$ ls | wc -l
120

/mnt/r/Temp$ ls icons/ | wc -l
111

# 下载方式是手动把站点网址替换成下载命令。
# REGEX:
# ^(.+?)://(.+?)/(.+?)$
# TO:
# wget "$1://$2/$3" -O $2.ico

/mnt/r/Temp$ du -sh icons/
1.4M    icons/
/mnt/r/Temp$ ls -lah | grep ico.zip
-rwxrwxrwx 1 335K Apr  3 10:57 ico.zip

顺便也测试了一下imagemagick 默认参数转成png（无损），jpeg（有损）的结果。

$ convert $2.ico ../convertedpng/$2.png
$ convert $2.ico ../convertedjpeg/$2.jpeg

$ ls -lha | grep zip
-rwxrwxrwx 1 355K Apr  3 11:10 convertedpng.zip
-rwxrwxrwx 1 271K Apr  3 11:10 convertedjpeg.zip

差别不大其实，所以直接保持原有的ico应该是最优方案。

[Rhilip]

@MewX 支持，而且next分支正在往这个方向走。虽然我个人考虑更多的是站点关闭的情况。
另外：

1. 就文件大小来说，我认为不能仅看zip后的。（虽然在这个electron随随便便100M+的世界已经没人关心这么点大小了。
2. 就icon来说，我们是否需要对其进行一定的处理？比如说统一宽高。

[MewX]

看中分发的话，主要看压缩后大小；感觉现在已经很少有人在乎解压后的大小了吧，硬盘有点便宜了。压缩前差不多1.5M，其实不大。

至於统一宽高，可以有多个角度思考。

• 统一到最大宽度？会更加浪费空间。
• 统一到一个指定的中档宽高？那么会损失高分辨率的icon。
• 统一使用原始文件？代码适配可能需要麻烦些，然后如果文件metadata有identity信息可能对贡献者产生麻烦。

总体来说，感觉统一宽高不是很有必要，但是可能最开始的话有必要统一转码，去掉metadata（不确定，但是以防万一？）。

[Rhilip]

icon都有identity我个人觉得不太可能。next分支中，我对downloader的icon是统一到128x128的，这个数量不多也相对容易。

---

另外还有一个问题，就是在目前版本中，我们支持自定义站点（虽然这个口子（包括其他一些涉及自定义脚本的口子）我准备在next中封上）。那么对于这类用户自定义站点，icon势必不可能进pack中，这块后续怎么做合适些？

[ted423]

@Rhilip base64写到配置里？用户可以自己改

[Rhilip]

@Rhilip base64写到配置里？用户可以自己改

（不会有人这么做吧，一定过不了 Code Review 的）

https://github.com/ronggang/PT-Plugin-Plus/blob/069661e6b9f4a1adec52f57174d6a05e518e586e/packages/site/src/types/site.ts#L107-L113

[MewX]

icon都有identity我个人觉得不太可能。

确实，我也觉得不太可能，不过考虑到cabal能在邀请码交易网站蹲点，可能什么都是有可能的吧 LOL

next分支中，我对downloader的icon是统一到128x128的，这个数量不多也相对容易。

听起来不错，但是有个问题就是图片按照什么算法来扩大。参考

• https://legacy.imagemagick.org/Usage/filter/
• https://en.wikipedia.org/wiki/Image_scaling

个人比较倾向于用 convert --filter point。但是确实需要一个统一的规范。

---

在目前版本中，我们支持自定义站点（虽然这个口子（包括其他一些涉及自定义脚本的口子）我准备在next中封上）。那么对于这类用户自定义站点，icon势必不可能进pack中，这块后续怎么做合适些？

确实是个好问题，也就是说还要对自定义的设定做兼容，但是最终还是需要最终汇总到repo里面，这样才能添加icon。

[ted423]

@Rhilip 没看懂，我指的用户可以自己填base64,然后保存到个人配置中，类似passkey那样，原有的自定义界面咋样我不记得了，太久没用了

[Rhilip]

1. downloader的icon基本是从更大的512降下来的，不涉及扩大，相对容易。。
2. size的icon，我初步考虑是从 32（很多站点都是这个）, 48,56 （48和56对于多数站点需要scaling） 中选一个，后面展示的时候，再用css的width和height来调整。
   目前使用的大小为 我的数据列表 18， 时间轴 38， 站点新增 40
3. 关于兼容，我目前在next中这么定义，按次序来做（2和3可以再考虑考虑）。

https://github.com/ronggang/PT-Plugin-Plus/blob/069661e6b9f4a1adec52f57174d6a05e518e586e/src/background/service/favicon.ts#L5-L11

[MewX]

👍 看起来还不错，另外3可能不需要局限于png文件，ico文件也可以接受应该，也是无损的。

[Rhilip]

@Rhilip 没看懂，我指的用户可以自己填base64,然后保存到个人配置中，类似passkey那样，原有的自定义界面咋样我不记得了，太久没用了

直接以base64的形式填入会扩大配置文件的体积。我个人是倾向能内置icon直接内置，不能内置的还是和原来一样。我们来请求文件。

[MewX]

我觉得独立文件更好，这样code review更方便，可以直接预览，而不用手动复制base64然后找个网站解析一下再看。

如果一个图标有30K，相当于有一个超长行在文件里，编辑文件比较痛苦。

[ted423]

@Rhilip 我指的自定义站点。因为之前看到有提到自定义站点

[Rhilip]

@ted423 自定义站点走老路子，直接写icon url在配置中。

[Rhilip]

👍 看起来还不错，另外3可能不需要局限于png文件，ico文件也可以接受应该，也是无损的。

从自动加载的角度来说，我个人觉得应该对其进行限制，要么 ico 要么 png。
除非我们每个都将icon写入配置文件，并约定如下：

{
     icon: './site.ico';    //  ./ 开头 从 `icons` 目录下加载，由webpack进行管理
     // 如果是 png 必须声明，如果标准的 `./{site}.ico` 则不需要
     // 这样也能实现icon的复用，例如某些nphp站点使用默认图标，直接 `./nexusphp.ico` 就行
}

{
     icon: 'https://example.com/favicon.ico';   // http开头，远程加载并缓存base64
}

{
     // no icon，如果有  `./{site}.ico` 文件，则使用，没有则走页面解析道路
}

另外，我简单测试了下：

• 如果放在 public/assert 目录下，则 vue-cli(webpack) 不对其进行管理，那么我们怎么判定icon存在需要考虑，在之前next的写法中，我是用 brower.runtime.getUrl + axois 的方式。
• 如果用 vue-cli(webpack) 进行管理，即 import.meta.webpackContext 的话，vue-cli 默认不对ico文件进行加载，需要进行 chainWebpack 改写。虽然可以前置判断，但是输出的文件都堆在了 dist/img 下，会不会过于杂乱（虽然也没人看）？
  

[MewX]

如果统一的话确实png更好些，空间也不会膨胀多少因为和ico都是无损的。

判断icon存在直接就用指明目录的方式呗？我觉得放在 PT-Plugin-Plus/resource/sites/* 文件夹里已经比较直观了，我个人倾向于

{
     icon: './site.ico';    //  ./ 开头 从 `icons` 目录下加载，由webpack进行管理
     // 如果是 png 必须声明，如果标准的 `./{site}.ico` 则不需要
     // 这样也能实现icon的复用，例如某些nphp站点使用默认图标，直接 `./nexusphp.ico` 就行
}

这样贡献者想添加站点的话不至于到处找目录，本来pt圈的程序员就不多，贡献开源的难度降低一些也好。

[Rhilip]

如果统一的话确实png更好些，空间也不会膨胀多少因为和ico都是无损的。

统一png的话，意味着多数站点的favicon不能直接使用，这些favicon的大小也多是32的。
而且从目前 config.json的统计来说，ico更多。

[MewX]

其实转成png也就是一行指令的事 convert a.ico a.png，但是好处是空间大概率减小 + 可以只保留最高分辨率的icon。

P.S. ico文件很多是内置多个分辨率的图片的，比如一个ico文件里面可能包含了：16x16, 32x32 ... 256x256的多个图片。看如下就是转码成了多个图片。

• PNG

$ ls -alh
total 615K
-rwxrwxrwx 1 mewx mewx 1.5K Apr  3 11:09 1ptba.com.png
-rwxrwxrwx 1 mewx mewx 1.3K Apr  3 11:09 aidoru-online.me.png
-rwxrwxrwx 1 mewx mewx  884 Apr  3 11:09 alpharatio.cc.png
-rwxrwxrwx 1 mewx mewx  550 Apr  3 11:09 animebytes.tv-0.png
-rwxrwxrwx 1 mewx mewx  775 Apr  3 11:09 animebytes.tv-1.png (低分辨率可以删除)
-rwxrwxrwx 1 mewx mewx  960 Apr  3 11:09 animebytes.tv-2.png (低分辨率可以删除)
-rwxrwxrwx 1 mewx mewx 1.2K Apr  3 11:09 animebytes.tv-3.png
...

• ICO

$ ls -lah
total 1.4M
-rwxrwxrwx 1 mewx mewx 4.2K May 24  2018 1ptba.com.ico
-rwxrwxrwx 1 mewx mewx  894 Jun 15  2016 aidoru-online.me.ico
-rwxrwxrwx 1 mewx mewx 1.2K Nov  8  2020 alpharatio.cc.ico
-rwxrwxrwx 1 mewx mewx  32K May 15  2021 animebytes.tv.ico
-rwxrwxrwx 1 mewx mewx 5.4K Apr 25  2017 animetorrents.me.ico
...

[Rhilip]

@MewX convert操作对非专业来说是不是过于困难，要么两个在未声明的情况下同时查找 .png 和 .ico，优先使用ico？

[MewX]

@MewX convert操作对非专业来说是不是过于困难，要么两个在未声明的情况下同时查找 .png 和 .ico，优先使用ico？
都查到了png为啥还要使用ico😂😂😂

前面不是说要统一嘛，所以我就觉得统一支持png比较好；如果支持两个格式的话就没问题了呀，先查询是否有png（因为各方面而言png都是比较高效的），再查询是否有ico如何？

另外我有点晕，这个icon文件目录不是指定在设置里面了嘛，不需要查询吧😅

[Rhilip]

(import.meta.webpackContext()).keys() 会生成一个 Array<./${string}.${"png" | "ico"}> 对应 icon目录下的文件，是在这个array中查找

const packedIconContext = import.meta.webpackContext("../icons/", {
  regExp: /\.(ico|png)$/,
  mode: "eager"
});
const packedIconList: Array<`./${string}.${"png" | "ico"}`> = packedIconContext.keys();

[MewX]

oh，原来要用 import.meta.webpackContext。 输出的文件都堆在了 dist/img 下确实有点不简洁，更新版本的时候就会添加新的文件了。那感觉 public/asset 还是好些，因为可以自己管理。

那要不直接去掉icon这个field，然后标注一下图标请复制到 public/asset目录？ 🤣 迷茫了，要不依然在site目录加icon，然后编译脚本自动把它们复制到 asset目录，自动改名，这样对贡献者友好些。