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

[Derek B. Noonburg]

Hi Hin-Tak,

I tried ghostscript (version 9.22 on Linux), and the dots look correct
there, both with X11 output and PNG (png16m).  Same for ghostscript
9.25 on Windows (cygwin) with png16m output.  I still haven't been able
to reproduce any problem with those dots on my Linux or Windows systems.

Were you able to try xpdf and/or ghostscript on a different Linux
system (or VM)?

- Derek


On Tue, 2 Oct 2018 16:50:33 +0000 (UTC)
Hin-Tak Leung <address@hidden> wrote:

>  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...      
> 
>