(just the accompanying issue for ghostscript as Bug 694093 for mupdf - filed under 'Font API' for the moment but may change it later) CJK bracket types (U3008 - U3011, U3014-U301B) should be rotated clockwise in vertical writing. I was shown a pdf where poppler-based applications (xpdf/evince/okular) do it correctly (from the libreofffice japan guy during the printing summit last week), while mupdf is wrong in one way and ghostscript is wrong in the opposite (180 degree from mupdf) direction for the unicode characters U300C and U300D. Don't know whether it is rotation within poppler or an alternate glyph(using the -V chacteracter hints), but poppler does it correctly and differently from either mupdf/ghostscript. mupdf differs from ghostscript, and both are wrong. I'll either try to get hold of that test file, find a public example, or make one.
Created attachment 9930 [details] vertical writing japanese pdf Note the positioning and rotation of the braces, as well as the punctuations.
compared to acrobat reader (if you don't read CJK natively...). On the original linux system I saw it on, (probably not using DroidSanFallback), the braces are rotated 180 from mupdf's - and both wrong. With up-to-date gs from source, and embedded DroidSanFallback, the braces are alright, but the punctuations - the 3rd and 4th glyphs from top-right downwards, are 180 deg rotated from how they should be.
What happens if the CID font is embedded? As it *really* should be, in-line with the spec.
If I understand correctly, truetype fonts have some sort of alternative glyph support for text-run direction being vertical? You probably need to emulate that kind of behavior with DroidSanFallback somehow. I am just the messager... Japanese natives expect it to work (somehow) and are rather surprised that it doesn't.
(In reply to comment #4) > If I understand correctly, truetype fonts have some sort of alternative > glyph support for text-run direction being vertical? You probably need to > emulate that kind of behavior with DroidSanFallback somehow. > > I am just the messager... Japanese natives expect it to work (somehow) and > are rather surprised that it doesn't. End user expectations do not, necessarily, dictate what is "correct" behaviour..... Using a different font to the one used when authoring the document is *always* prone to problems of missing/mismatched glyphs, incompatible metrics and so on, and the problem is only compounded when talking about CIDFonts. What's most important here is whether there is a problem when displaying with the intended font, as that illustrates a genuine bug with our font machinery, or whether the problem is caused by relying on a substitute font which (as *clearly* stated in the documentation) runs the risk of this type of issue arising.
Configuring Ghostscript to use the same substitute font as poppler based apps for the CIDFont MS-Mincho results in output that I believe is correct - on my system poppler uses "wqy-microhei.ttc". So the font code is correct, given an appropriate font. As is mentioned in the documentation, DroidSansFallback.ttf is used as a last ditch fallback to output *something* hopefully legible (feedback from users suggested that this was preferable to throwing an error, which is, strictly speaking, the correct behaviour). The documentation is also clear that relying on substitute font like this is likely to result in wrong or missing glyphs. We chose DroidSansFallback because it has very good glyph coverage (especially given it's file size), but it is not comprehensive. Basically, I feel this is not unreasonably behaviour.
In MuPDF we've fixed this problem by using a separate substitute font for horizontal and vertical writing modes. MuPDF's DroidSansFallback is a TTC which has both variants. See bug 694093 and commit 0f0653cac62c7dbcd4b4cd2ea57640769271365c in mupdf.git
In the default configuration, brackets are now correct but punctuation is still misplaced.