Qijia Yang

+1 after one year, or you can try [EIDE](https://em-ide.com/), it's a good alternative to platformio

Helpful idea :smiley:

I meet the same bug too. PLEASE merge the pull requests.

已排查接线问题， NXP LinkServer配置如下：  

已经识别上了而且LinkServer连接上了  身边暂时没有其他的DAP

I have created a [PR](https://github.com/sivan/heti/pull/123)

的确有可能与字体有关，我使用了自定义的font-stack： ``` "JetBrains Mono", "Ubuntu Mono", "Times New Roman", "Noto Serif CJK SC", "Noto Serif CJK TC", "Noto Serif CJK HK", "Noto Serif CJK JP", "Noto Serif CJK KR", "Microsoft...

目前排查发现bug与`Noto CJK`（思源宋体）有关 复现：  我做了一个小实验，在不同字体下观察`。`的样式，类似这个[帖子](https://tex.stackexchange.com/questions/689789/apostrophe-for-noto-cjk-fonts) 这是`Noto Serif CJK SC`的结果  这是`SimSun`的结果  看来这个bug有可能是由于Chrome预先减少了思源宋体的空隙而造成的问题，我提议可以在我的解决方案前再加上一个CSS选择器特判思源宋体以处理这个问题，更好地支持思源(Noto CJK) 系列字体

在这个[commit](https://github.com/sivan/heti/pull/123/commits/b5b6b7801a44e7d746c60e0b079222e8b4e5e3b0)中，我按照上述思路进行了实现，并在Chrome上验证了bug修复效果，同时在演示网站上增加了“思源宋体按钮”

首先，确实为了适配更多的字体（例如思源宋体）可能需要更多的dirty work，`heti`是否要支持更多的字体（诸如思源宋体）还是取决于项目作者您。不过鉴于早在3年前就已有[关于支持思源宋体的issue](https://github.com/sivan/heti/issues/63)，而且思源宋体安装较为广泛，我认为还是存在一定的必要。 其次，我又注意到另外一个bug，heti（原始版本，非本fork版本）在一个没有安装`Heti Hei`但用户安装了思源宋体的系统上（如`Ubuntu`等Linux），选择`heti--sans`（即`Heti Hei`）时，Chrome会自动为`；`这样的标点符号匹配为字体`Noto Sans CJK JP`，从而导致了与此issue类似的问题  换句话说，即便heti选择不提供思源宋体字体选项，在没有安装`Heti Hei`但安装了思源宋体的Chrome用户眼中，使用`heti--sans`也会严重影响排版效果。 然后，有关处理的方案，我十分赞同您的思路，确实应该根据实际选择的字体来应用我那样的处理方法，但是根据[这篇帖子](https://stackoverflow.com/a/64264842)来看，似乎办不到根据实际字体渲染不同的样式。因此，我还是觉得我的处理办法相对更加妥当，理由如下： - 对于思源宋体（以及其他有可能出问题的字体），与其错误添加样式`margin-inline-end: -0.5em`（即暂不处理目前的heit），不如不添加，因为错误地添加`margin-inline-end: -0.5em`带来的结果是灾难性的，而不添加带来的结果则是难以察觉的轻微瑕疵 - 开发者使用`heti--noto-sans`和`heti--noto-serif`意味着开发者应该明白此样式在没有安装思源宋体用户上的表现效果，类似于，使用`heti--sans`样式意味着开发者应该明白此样式在没有安装`Heti Hei`用户上的表现效果，这是开发者的责任 另外，其实我认为可能还有另外一种解决办法的思路：Chrome特殊处理自家的思源宋体应该是有某种机制的，由于个人能力有限，不太了解等宽字体等等一系列字体概念，没有明白背后的真正原因，如果能定位到背后的真正原因，应该会有更加优雅，更加普遍的解决方案。 最后，再次感谢作者百忙之中的维护和审阅