Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)

[Hin-Tak Leung]

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 <address@hidden> 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 <address@hidden> 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...