Hi Derek,
I found one other app with the missing dot problem on the first page -
ghostscript. On X11, the dots are as missed as xpdf, while when running
ghostscript to convert to png (png16m), the missing dots "re-appears" but as
narrow dashes. Maybe something to do with treatment of transparencies/alpha ?
I checked Acrobat XI (11) on windows and Acrobat 15.x on wine and they both
have problems with page 2 and 3. But my android device is running acrobat
reader 18.x - I hope the version is similar and not just the year!
About the glyph origin of the 2nd page. I think your observation is correct and
expected. The 2nd and 3rd glyph seems to be SIL's way of simulating a sanskrit
ligature(?) with contextual alternates. i.e. the 2nd glyph is supposed to be an
accent/diacritic-like attachment to the 3rd glyph. In the android version they
are still separate, but with other fonts, e.g. microsoft's mangal devanagari,
it is a single ligature with the 2nd shape touching the 3rd shape.
I'll probably keep digging and see if anything comes of it. I would normally
assume somewhere the generator is wrong (harfbuzz, cairo, latex, ghostscript),
but one viewer on one platform can display the intended result, and that viewer
is acrobat reader (on android), that needs to be looked at carefully...
Hin-Tak
On Monday, 1 October 2018, 20:12, Derek B. Noonburg
<[email protected]> wrote:
Hi Hin-Tak,
Regarding the first issue (missing dots -- FontVal-TypoLabs2018.pdf page
73 / FontVal-x.pdf page 1): I haven't been able to reproduce this. I
tried the 32-bit and 64-bit XpdfReader binaries (the same ones that you
can download from my web site), and they all work correctly. The fact
that you're seeing different output from xpdf and pdftopng is strange
-- I don't know of anything that would cause that. They use the same
code internally. If you can run my XpdfReader binary on another system,
or a clean Linux VM, I would interested to hear the results.
For the other two issues: I checked both pages with Acrobat X on
Windows and with ghostscript on Linux, and they all show the same
problems. I'm not sure why Acrobat Android would be different, but I
suspect the problem is in the PDF file.
I took a look at the third issue (FontVal-x.pdf page 2), just because
it seemed quicker to isolate than the Arabic. One of the glyphs in the
font appears to have an origin that's significantly to the right of the
glyph's leftmost extent. I'm wondering if there might be a bug in
whatever software generated the PDF file (LaTeX?), such that the layout
doesn't account for that origin.
I'm guessing that the Arabic problem (FontVal-x.pdf page 3) is similar,
but I haven't checked. Let me know if you think it's unrelated, and
I'll take a look.
- Derek
On Mon, 1 Oct 2018 00:02:02 +0000 (UTC)
Hin-Tak Leung <[email protected]> wrote:
> Hi,
> Just recapping - http://htl10.users.sf.net/FontVal-x.pdf -
>
> The rendering issue with page 1 is GUI/QT only and does not affect
> topng. I double-checked the glyph positioning issue with page 2 and 3
> with the 32-bit binary on your web site too - that should rule out
> any issue from local customization. Oh, I tried okular too - it uses
> libpoppler which was derived from xpdf - and okular uses QT too but
> is not affected as far as page 1 is concerned. If the Artifex folks
> are listening - I tried building the latest mupdf from git and git
> module update --init - that's basically static linking every library
> from an Artifex tagged preferred/unmodified version . Page 2 and 3 's
> glyph positioning problem is seen there too (and other viewers on
> Linux, including acroread 9.5). So I'll file a bug with Artifex at
> some point. I guess I'll give windows acrobat reader on wine on Linux
> at some point, and try mupdf on my android phone too...
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
