From: Paul V. <pa...@vi...> - 2020-02-25 12:24:45
|
Mark Rotteveel wrote: > Whenever you generate a new msmincho.xml, see if it contains > this element: > <bf us="8192" ue="8213" gi="753"/> > or something similar with us <= 8203 <= ue. > If you find such an element, cut out 8203 by replacing the > element with two ranges, in this case: > <bf us="8192" ue="8202" gi="753"/><bf us="8204" ue="8213" gi="765"/> > Note that the first element keeps the original value for gi. > The gi of the second element is calculated as follows: > gi(2) = gi(1) + us(2) - us(1) > """ > > After some experimentation, I didn't removed the 8203 character, as I > didn't see anything wrong with rendering, but it might be easy to miss. > Any idea what I should be looking for? I dug this up from the tracker: > Zero-width spaces in the .fo file (we use them in file names, URLs etc.) show up as normal spaces in the Japanese (and other non-Western?) PDFs, ruining the appearance of the elements in question. > The MSMincho metrics file contains an entry for ZWSP with (evidently) the wrong character width. Removing the entry resolves the issue. A related bug (ZWSP acts as backspace when the font is embedded in the PDF) has been fixed in our own build of the patched FOP trunk. But that was 13 years ago. I'm sure they fixed the font files since then, so the above comment *probably* doesn't apply anymore. In order to test it, you could insert a ZWSP somewhere in a Japanese source and see if it comes out as a visible space in the PDF. Or, as you suggested, we could just wait until the next Japanese document needs to be built. Cheers, Paul Vinkenoog |