柳鲲鹏

改用JDK8改名。

我初步研究了一下，还真是。现实是如果使用XIMPreeditPosition初始化，XCreateIC失败（返回NULL）。原来代码中也没这个东西。代码很久了，于是我又重新研究了一下。实际上要得到的并不是屏幕位置，而是与焦点窗口左上角的领衔。几个月之后，好像终于有人review了。

我也尽力，争取把这些修改逐步提交到JDK官方源码。而JDK官方事务繁多，整合一个修改都要几个月，我也很无奈。泰山JDK8这么好的东西，就这样完蛋了，心里好难过。里面多项改进，都是JDK的首次。我很早就建议把泰山JDK8搞成国家的科研项目，为软件业贡献。

对你正在做的事情提供一个完整的描述和解释，为什么它是正确的解决方案 你做过什么测试，没有做过什么测试，有什么风险——包括不使用即时消息的应用程序 换句话说，当你(我希望)明白你是如何决定这是正确的解决方案(而不仅仅是复制 有人在bug报告中提出了什么)，评审人员希望听到您的意见。所以花点时间把它写清楚。解决JDK输入法光标跟随，专门发过一篇论文，要回答清楚还是很容易的。为什么WINDOWS能够光标跟随，LINUX无法做到。我做了哪些研究工作。

JDK17是LTS版本。为了将来集成代码，所以先编译试试。下载带ga的版本，表示正式发布。

JDK11是LTS版本。为了将来集成代码，所以先编译试试。下载带ga的版本，表示正式发布。

git rebase是参与gitlab上freetype时学会的。

仔细整理修改了代码，提交到JDK。

我看过他的录像，用ECLIPSE跑的JAVA程序（可能是MIPS机器上），确实是跟随光标移动。后来泰山OFFICE某个版本出问题，是因为代码改错了。于是反复搜索、测试，都没找到解决办法。他声称解决了，也根据我的要求录像了。我就纳闷了，亲自一试，果然没有解决。

　　最近为了解决这个BUG：New changes for 8u should go to GitHub - openjdk/jdk8u-dev: https://wiki.openjdk.org/display/jdk8u. This tree is for critical regression fixes for the next release only.@quantum6 From the bug description it sounds like this is an issue in lat

其实我也没仔细研究，就是看着两个命令，就编译了。难以置信，已经JDK21了。我的系统是UBUNTU 22。

使用JDK17(或者其他高版本）编译，在JDK8运行。而这个函数在二者的签名不一样。把出问题的类，使用JDK8进行单独编译，然后再替换进去。比如吾也想用JDK8编译，结果编译时明确要求，必须使用JDK17。

在编译jogamp 2.4.0的过程中，直接体会到二者的差异。看了一下JDK8，其实除了JRE目录，其他几个目录并无必要。JDK8有amd64/loongarch64的目录。以前搞个包复制到ext下，已经不灵了。

点击上图中的“New pull request”，然后选择正确分支。

其实之前就发现问题，昨天看到问题太明显，于是进行了研究。然后就找到了解决办法。可以看出来，缩字也有问题。

字段赋值：textAntialiasHint。从参数FontStrikeDesc得到设置。在这里产生FontStrikeDesc()需要注意的是，两处使用aahint。

终于找到了：GitHub - loongson/jdk8u: https://wiki.openjdk.org/display/jdk8u

VS2017目录结构有所变化，所以要进行一番修改。

Font2DFileFont。

　　前几日，研究字体时发现kerning的特性。经过一番工作，泰山JDK8率先支持！　　按照开源协议，BUG及解决办法，都上报到JAVA。具体参考：Bug ID: JDK-8298257 Kerning information from font

getCodePointAdvance()处，mapper.charToGlyph(cp)得到？的图元索引(66267)。这么一判断，自然为0了。

如果是英文，相信各位可以方便的判断出来大小写。

之前记得某些情况下，Font.canDisplay()有问题。今天试了一下Times New Roman字体对泰的结果，得到了false，说明正确工作了。如果index合法（落在startCount和endCount之间），就可以找到索引。missingGlyph初始化为-1，TrueTypeGlyphMapper()中初始化为0。如果返回的glyph与missingGlyph不同，就可以显示。这个函数中，charToGlyph()得到字符图像索引，如果是-1就是无法显示。

某些场合下，需要浮点字体，而Font的构造器中，需要的是整数。是不是就没办法了呢？实际上JDK是支持浮点字体的。最后，可以通过Font.getSize2D()得到浮点字号。对变形器使用浮点操作就可以了。

pointSize的命名，疑似不准确。或者是FreeType的磅？调用一个私有浮点构造器。从这里可以看到，JDK是支持浮点字体的。泰山JDK为此专门修改，开放并扩充了构造函数，允许传递浮点。这个函数需要的字号有6位定点小数，所以前面乘64。从传递的参数matrix中获取数组。传递字号，保存在size字段中。字号信息保存在matrix中。也就是构造了一个变形器。

正确：jogamp.opengl.x11.glx.X11OnscreenGLXDrawable(两层继承：X11GLXDrawable, GLDrawableImpl) implements GLDrawable。错误：jogamp.opengl.egl.EGLDrawable(继承GLDrawableImpl)到了这里，直接原因清楚了。上述类，仅在getBestConfiguration()新建。在setVisible()的时候，嗝屁了。doWork()调用。

在这里进行跟踪，发现是compositeGetOverlayWindow导致的。吾仔细想了半天，莫非是窗口产生了没有释放？别说，还真找到了一个释放函数：XCompositeGetOverlayWindow。加上之后，果然不死了。泰OFFICE有个BUG，说在UOS+KIRIN系统上，截屏卡死。这么怪异的问题，当然很难解决。通过对比正确顺序，发现：正确的时候XGetImage()返回结果，错误的时候为NULL。不死的问题解决了，拿到的是黑屏，也就是没有得到数据。使用的是Robot进行屏幕。

之后是本地函数getGlyphAdvanceNative()

getFontMetricsNative是本地函数，然后新建StrikeMetrics对象。FTScalerInfo.face中的值：ascender/descender/height。

【代码】Github参与jdk8u，提交的PR提示：Testing is not configured。

吾提交代码到jdk8u后，收到一个消息：Oracle Contributor Agreement。

代码修改完毕，也提交到自己的库。

泰山JDK8有很多修改，在某些方面已经是完全不同了。成功参与FreeType修改之后，吾就想，应该参与JDK8的修改。

在JDK的TrueTyepFont类中，看到以下注释：/**/

因为修改了多个文件，修改的地方也比较多，所以直接复制了整个文件。其中如果有编译不过的，直接删除即可。当然现在有更好的写法了，思路还是一样的。

完成了泰山JDK8完美支持TTC文件之后，吾思维扩展了一下：如果仅仅是想从TTC中获得全部字体名，用不着修改JDK，直接就可以。当然，这样仅仅是获得字体名。要想使用其中的字体，必须修改JDK。

batang.ttc中，共有4个字体：Batang, BatangChe, Gungsuh, GungsuhChe。由图中可以看到，4行文字的英文各不相同。在前面博文中有说明。

开始吾想自己解释字体文件。于是找了FontForge，结果编译没有通过……回头一想，JDK已经支持TTC，吾何不在此基础上处理？构造器中，先把字体名全部读取出来。然后再从字体名中找到索引，重新初始化。这个办法是比较笨的，以后考虑优化一下处理。如前面博文所述，其实JDK是能够认识TTC字体文件的。做起来好像也不难，因为咱有泰山JDK啊。没有这个东西，外部字体名传递进来，也是傻眼。如果字体名有效，则忽略字体索引。前面两个问题解决了，这个就容易了。

于是了解了一下，原来字体文件（TrueType）有两种：一种是单一的字体（TTF），还有一种是多种字体（TTC）。同事报怨，泰山OFFICE可用字体太少。吾当时就奇怪了：就那么几个字体，让吾给汝变出来？同事说，别的软件字体多啊。那么，是不是改了就对了呢？咱有泰山JDK8，想改还不容易？随口一句：有自己的基础软件，真的好方便啊。使用FontForge可知其中有两个字体，参数中无法指定。从绘制效果来看，完全一样。这个结果是不是对的呢？得到的结果都是：新宋体。这说明JDK确实是能处理TTC。

经过搜索、分析、检查，实际上可用的Windows SDK只有v7.1A，其他的都不行。这个错误是吾编译OpenJDK8时遇到的。这是第二次编译，第一次编译没有记录这个错误。难道是系统装的问题？是不是很神奇的通过了？