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 _______________________________________________ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
