冒号和分号的位置

[prinwis]

ptex-ng 对中文的冒号和分号处理是默认居中，通常应该是在左下的，这是刻意设置成这样的吗？另外当它们在行末的时候，与前一字的间距似乎有点大。

[aminophen]

I'm not the author ptex-ng, but I'm a maintainer of TFM files which can be used on ptex-ng.

I think the design of colon and semicolon (left-aligned or center-aligned) varies between actual fonts. What font are you using?

[prinwis]

@aminophen
I'm sorry for my poor English.
The font in the previous figure is FandolSong-Regular, I tried several other fonts, their semicolon and colon are in the lower left, as prescribed by the PRC's specification. The following figure shows another font (FZXSS).

Following figure shows semicolon and colon in FandolSong and FZXSS.
FandolSong


FZXSS

[aminophen]

Thanks for the information; hmm, it seems that fonts are correct (left-aligned), so something might be wrong in ptex-ng or uptex-fonts (tfm/vf).

I'm not so familiar with ptex-ng, so could you give me the source code of the example? I'll examine.

[aminophen]

I think I managed to reproduce your results by trial and error; and, If my trials are valid, the problem lies in the metrics, not ptex-ng.

In the current version of uptex-fonts (available from CTAN, 2017-01-03), Chinese metrics "upschrm-{h,v}.{tfm,vf}" are not optimized for Chinese. They share the PL source (property list for TFM) with Japanese metrics "upjisr-{h,v}.{tfm,vf}", simply because we are Japanese and did not know how to set punctuations properly for Chinese.

(CTeX-kit's "zhmetrics-uptex" is maintained by Chinese, but they incorporated the PL source from our "uptex-fonts" without modification, so "upzh*-*.{tfm,vf}" are suffering from the same issue.)

---

Incidentally, just a few weeks ago, I started to consider about improving the situation. At the beginning I didn't know much about Chinese typesetting, but with the helps of Chinese users (see CTeX-org/ctex-kit#292), I managed to create a new version optimized for Chinese (available from vf-regen branch).

With the new version of "upschrm-{h,v}.{tfm,vf}", the result seems correct.

\documentclass{ujarticle}
\pdfpagewidth\paperwidth
\pdfpageheight\paperheight

\jfont\xxx=ot:FandolSong-Regular.otf:upschrm-h at 12pt
\jfont\zzz=ot:FandolSong-Regular.otf:upjisr-h at 12pt

\def\boundary{\vrule width1pt height12pt}
\def\TEST{于是她近乎歇斯底里的喊道：“这真的不是我做的！”}

\begin{document}

\noindent\texttt{new version of ``upschrm-h''}\par
{\xxx\boundary\TEST\boundary}

\noindent\texttt{cf.) ``upjisr-h'' (= old version of ``upschrm-h'')}\par
{\zzz\boundary\TEST\boundary}

\end{document}

If you like it, then I will release the new version of "uptex-fonts" on CTAN (and TeX Live) when I have enough time. (There is another issue regarding Japanese vertical writing and I'm working on it...)

[prinwis]

@aminophen Thanks, I download your patch and replace the old, it behaves well. If you have time, please release your patch.

[aminophen]

I'm reconsidering this issue, and I find there is another problem in ptex-ng itself.

The example in my previous comment is for "platex-ng" (uplatex on ptex-ng), and it can be rewritten for "uplatex" as follows;

\documentclass{ujarticle}
\AtBeginDvi{\special{papersize=\the\paperwidth,\the\paperheight}}

\jfont\xxx=upschrm-h at 12pt
\jfont\zzz=upjisr-h at 12pt
\AtBeginDvi{\special{pdf:mapline upstsl-h UniGB-UTF16-H FandolSong-Regular.otf}}
\AtBeginDvi{\special{pdf:mapline uprml-h UniGB-UTF16-H FandolSong-Regular.otf}}

\def\boundary{\vrule width1pt height12pt}
\def\TEST{于是她近乎歇斯底里的喊道：“这真的不是我做的！”}

\begin{document}

\noindent\texttt{new version of ``upschrm-h''}\par
{\xxx\boundary\TEST\boundary}

\noindent\texttt{cf.) ``upjisr-h'' (= old version of ``upschrm-h'')}\par
{\zzz\boundary\TEST\boundary}

\end{document}

With "uplatex" + "dvipdfmx", I get

The result is different from "platex-ng", in that a colon for upjisr-h is also left-aligned. I think the difference is caused by the regression in ptex-ng, which does not read VF file.

In JFM files (which are read by *TeX = ptex/uptex/ptex-ng), the widths of punctuations are truncated into halfwidth and the substituting halfwidth "JFM glue" is inserted by *TeX. On the other hand, DVI drivers (dvipdfmx, dvips and libdpx = embedded in ptex-ng) assume all-fullwidth metrics for actual fonts. To resolve the gap, VF files are required; VF files to be used with JFM contain many "MOVERIGHT" DVI commands for punctuations, which shift punctuations horizontally.

It seems that ptex-ng does not read VF files at all, so the punctuation characters are wrongly shifted by the amount of JFM glue inserted by *TeX. I think this is a serious problem lying in ptex-ng.

So, could you re-open this issue please? > @prinwis

[prinwis]

I find title marks isn't correct when it's in the beginning of paragraph, and in some fonts, fullstop's position is shift up.

[Man-Ting-Fang]

I find title marks isn't correct when it's in the beginning of paragraph, and in some fonts, fullstop's position is shift up.

如果你用jsclasses的话，可以解决第一个问题（注意，对于upLaTeX和ApLaTeX，要使用uplatex选项）。如果不想用jsclasses的话，可以用bxjaprnind宏包解决第一个问题。

其实，这个不是ApTeX引擎的原因，所有的pTeX系列引擎都这样。除此之外，JFM至少还有一个bug，我正在写一个宏包，用来（部分地）解决这两个问题，应该会很快写完（吧）……（这两个bug似乎不太可能在JFM自身上解决，需要通过宏才行。）

第二个问题，请给出详细一点的信息。不过这个可能是字体的问题。JVF可以在竖直方向上平移，但都是整体平移，用来调整整个字体的基线；ApTeX如果用自己的ot:式的语法的话，目前似乎无法在竖直方向上移动。

[prinwis]

@Man-Ting-Fang 经查，第二个确实是字体的问题。

[Man-Ting-Fang]

如果你用jsclasses的话，可以解决第一个问题（注意，对于upLaTeX和ApLaTeX，要使用uplatex选项）。如果不想用jsclasses的话，可以用bxjaprnind宏包解决第一个问题。

不过，无论是哪种方法，都无法确保在所有情形下都能解决，有时需要额外的设置，甚至自己手动处理。遇到无法自动处理的情形，可以在书名号（以及所有开符号类，如各种引号、括号等的前一半）前加上\inhibitglue（原语）或者是(u)pLaTeX提供的\inhibitglue的简短别名\<（但需注意，\<可能会与其他宏包有冲突）。

[aminophen]

@Man-Ting-Fang Thanks for your help. (I'm google translating to English ;-) )

JVF可以在竖直方向上平移，…ApTeX如果用自己的ot:式的语法的话，目前似乎无法在竖直方向上移动。

To summarize the limitation of ApTeX, we cannot utilize VF for shifting characters vertically or horizontally with on ApTeX's ot: grammer, right? But... I'm wondering about what to propose; is it possible to make ApTeX read corresponding VF if exists?

[Man-Ting-Fang]

To summarize the limitation of ApTeX, we cannot utilize VF for shifting characters vertically or horizontally with on ApTeX's ot: grammer, right?

I cannot find information about JVF in this comment and my test on JVF failed when using ApTeX.

But... I'm wondering about what to propose; is it possible to make ApTeX read corresponding VF if exists?

Sorry, I don't know, I haven't read the source code of any TeX engine...