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

[Hin-Tak Leung]

Hi Derek,
I have two rendering issues with xpdf, and the 2nd of which also affects every other viewers on Linux I have - mupdf, acroread 9.x , evince. But the file works correctly on acrobat reader on android, so it seems to be a rendering problem, and perhaps generic to Linux-based viewers - for the 2nd issue.
The file is http://htl10.users.sourceforge.net/FontVal-TypoLabs2018.pdf . Sorry it is a 17MB file - processing the eps alone does not trigger the problems.
Page 73 - the Devanagari accents, the dotted circles shows only 3 dots (should be about 8). Page 72 has a figure from png screen capture showing what it should look like.
Page 76 - the Arabic glyphs are not positioned correctly and so the writing is a bit broken up. Again page 75 has figures show what it should look like. This problem affects every viewer I find on Linux also - mupdf, evince, acroread 9.x . 
The figures were generated as eps's from harfbuzz / cairo with embedded fonts, then passes then latex and drips then Ghostscript. I first suspect a generic issue with one of the generating tools as the 2nd issue affect every viewer on Linux (the first issue is xpdf specific). But current acrobat reader on android display the expected result.
I tried also the official binaries (both 32-bit and 64-bit) from the xpdf website, just in case. (my system is mostly fedora 28, but the 32-bit freetype is 2.9.1 as is from fedora 29, while the 64-bit freetype is based on fedora 29's but modified with the current fontval patch)
I also have a small complaint about the new 4.0 GUI - the navigation forward/backward buttons don't do next/previous page, but does some kind of history navigation - e.g. If you do page 1, then jump to page 50 with the explicit page number input, then press the backward button, it goes back to page 1 rather than page 49. Also "n" and "p" don't work like the 3.0 motif/lesstif GUI... So navigation is a bit painful with the 4.0 GUI. 
Hin-Tak

[Derek B. Noonburg]

Hi Hin-Tak,

(I'm replying from a different address because that's where I'm
subscribed to freetype-devel.)

Post by Hin-Tak Leung
I have two rendering issues with xpdf, and the 2nd of which also
affects every other viewers on Linux I have - mupdf, acroread 9.x ,
evince. But the file works correctly on acrobat reader on android, so
it seems to be a rendering problem, and perhaps generic to
Linux-based viewers - for the 2nd issue. The file is
http://htl10.users.sourceforge.net/FontVal-TypoLabs2018.pdf . Sorry
it is a 17MB file - processing the eps alone does not trigger the
problems.
Page 73 - the Devanagari accents, the dotted circles shows only 3
dots (should be about 8). Page 72 has a figure from png screen
capture showing what it should look like.
Page 76 - the Arabic glyphs are not positioned correctly and so the
writing is a bit broken up. Again page 75 has figures show what it
should look like.

I wasn't able to reproduce this problem (or at least I don't think so
-- I don't read Devenagari or Arabic, but the results from xpdf look
similar to the screen captures you mentioned).

I'm attaching the output from pdftopng for those two pages. Can you
send me the output you're getting?

Post by Hin-Tak Leung
This problem affects every viewer I find on Linux also - mupdf,
evince, acroread 9.x.

Is there any chance that you have some configuration (environment
vars?) that affects FreeType, on your system? You mentioned that you
tried the binaries from my web site, which are staticly linked to
FreeType, so that should rule out anything but configuration.

The pre-built xpdf 4.00 binaries are linked to FreeType 2.8. I also
tested my current development code, using FT 2.9.1 -- same results.

Post by Hin-Tak Leung
I also have a small complaint about the new 4.0 GUI - the navigation
forward/backward buttons don't do next/previous page, but does some
kind of history navigation - e.g. If you do page 1, then jump to
page 50 with the explicit page number input, then press the backward
button, it goes back to page 1 rather than page 49. Also "n" and "p"
don't work like the 3.0 motif/lesstif GUI... So navigation is a bit
painful with the 4.0 GUI.

I chose to remove the next-page and previous-page buttons from the
toolbar, because I think that most people use keystrokes for those,
and I wanted to maximize the window space devoted to displaying the
PDF file. By default, PageDown and space are bound to next-page, and
PageUp is bound to previous page. You can add bindings for 'n' and
'p' in ~/.xpdfrc:

bind n any nextPage
bind p any prevPage

- Derek

[Hin-Tak Leung]

Hi Derek,
On Saturday, 29 September 2018, 02:58

I'm attaching the output from pdftopng for those two pages.  Can you

send me the output you're getting?
The first problem is not seen in the topng result, and only in the QT display (I try png also then look at the display again), so I have taken a photo of my screen quickly (the 4179 attachment) - see the dotted circles only shows 3 dots. The 2nd problem is in your topng result also - there are small gaps and positioning problems with the Arabic. I have attached screen capture of the correct rendering from acrobat android. I found a similar problem with a devanagari font also, and it is more obvious; so the android acrobat result is also attached - notice the bottom red glyphs, and compare how xpdf does it (this affects other viewers too).
I extracted the two pages, plus putting the new issue in the middle, as http://htl10.users.sf.net/FontVal-x.pdf , it is only 140k.

Hin-Tak

[Hin-Tak Leung]

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

[Derek B. Noonburg]

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)

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

[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 <***@glyphandcog.com> 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)

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

[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)

Post by 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
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)

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

[Alexei Podtelezhnikov]

Post by Derek B. Noonburg
Regarding the first issue (missing dots -- FontVal-TypoLabs2018.pdf

I was able to reproduce the missing dots with ftview in the embedded
file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL). With native
default hinter enabled, some dots are always missing with sizes less
than 57. There is no problem with autohinter or with hinting disabled.

ftview 48 RSOAVR+Lohit-Devanagari.ttf

Alexei

[Hin-Tak Leung]

Wow, thanks Alex. I was losing my mind wondering why others don't have the same problem :-).
I suspect the issue with page 2 and 3 is to do with opentype features - those fonts have gpos/gsub tables, which probably affect how glyphs are positioned.

Post by Derek B. Noonburg
Regarding the first issue (missing dots -- FontVal-TypoLabs2018.pdf

I was able to reproduce the missing dots with ftview in the embedded
file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL). With native
default hinter enabled, some dots are always missing with sizes less
than 57. There is no problem with autohinter or with hinting disabled.

ftview 48 RSOAVR+Lohit-Devanagari.ttf

Alexei

[Alexei Podtelezhnikov]

Post by Alexei Podtelezhnikov
I was able to reproduce the missing dots with ftview in the embedded
file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL). With native
default hinter enabled, some dots are always missing with sizes less
than 57. There is no problem with autohinter or with hinting disabled.
ftview 48 RSOAVR+Lohit-Devanagari.ttf

Specifically TrueType engine v40 and v35 do the damage. v38 is fine. Nikolaus?

[Werner LEMBERG]

Post by Alexei Podtelezhnikov
I was able to reproduce the missing dots with ftview in the
embedded file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL).
With native default hinter enabled, some dots are always missing
with sizes less than 57. There is no problem with autohinter or
with hinting disabled. ftview 48 RSOAVR+Lohit-Devanagari.ttf

Specifically TrueType engine v40 and v35 do the damage. v38 is
fine. Nikolaus?

The font is hinted with my ttfautohint program but using an older,
buggy version: For example, MS Visual TrueType reports

Glyph ID 2
Critical Error:
Inst: WS Storage index out of range. Index = 96, Range = 0 .. 95
At ByteOffset: 223 Of function: 4

In other words, Windows stops hinting and displays the glyph unhinted.
FreeType, on the other hand, tries to continue with hinting – in many
situations this is a good decision, but here we have a case where the
result is bad.

BTW, using the current version of Lohit Devanagari (2.95.4), which has
been hinted with a newer version of ttfautohint, the rendering is OK.


Werner

[Hin-Tak Leung]

Yes, search for E6047, or 'storage index out of range' in the reports I uploaded a couple of months ago - https://github.com/HinTak/FontVal-Tests-at-10pt/blob/fedora/fonts/lohit-devanagari/Lohit-Devanagari.ttf.xml

Same detailed information there...
I suppose I should file a bug with fedora...

Post by Alexei Podtelezhnikov
I was able to reproduce the missing dots with ftview in the
embedded file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL).
With native default hinter enabled, some dots are always missing
with sizes less than 57.  There is no problem with autohinter or
with hinting disabled.  ftview 48 RSOAVR+Lohit-Devanagari.ttf

Specifically TrueType engine v40 and v35 do the damage.  v38 is
fine.  Nikolaus?

The font is hinted with my ttfautohint program but using an older,
buggy version: For example, MS Visual TrueType reports

  Glyph ID 2
  Critical Error:
    Inst: WS Storage index out of range. Index = 96, Range = 0 .. 95
  At ByteOffset: 223 Of function: 4

In other words, Windows stops hinting and displays the glyph unhinted.
FreeType, on the other hand, tries to continue with hinting – in many
situations this is a good decision, but here we have a case where the
result is bad.

BTW, using the current version of Lohit Devanagari (2.95.4), which has
been hinted with a newer version of ttfautohint, the rendering is OK.


    Werner

[Hin-Tak Leung]

Post by Werner LEMBERG
BTW, using the current version of Lohit Devanagari (2.95.4), which has
been hinted with a newer version of ttfautohint, the rendering is OK.

Hmm, the versioning doesn't help - the one ships by fedora also says 2.95.4 in the name table.
Now that we know what to look for, I can reproduce the problem with the full font also, with ftview. It is glyph id 472, hinting on, force auto off, either v35 or v40. Just going up and down in ppem with the arrow key I get the dots to appear and disappear below about 55 ppem.
So fedora ships 2.95.4 that's different from your 2.95.4 :-(.
Hin-Tak

[Werner LEMBERG]

Post by Hin-Tak Leung

Post by Werner LEMBERG
BTW, using the current version of Lohit Devanagari (2.95.4), which
has been hinted with a newer version of ttfautohint, the rendering
is OK.

Hmm, the versioning doesn't help - the one ships by fedora also says
2.95.4 in the name table. Now that we know what to look for, I can
reproduce the problem with the full font also, with ftview. It is
glyph id 472, hinting on, force auto off, either v35 or v40. Just
going up and down in ppem with the arrow key I get the dots to
appear and disappear below about 55 ppem. So fedora ships 2.95.4
that's different from your 2.95.4 :-(.

I've downloaded the working Lohit Devanagari font from

https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ;

it has

<modified value="Wed Apr 26 10:34:57 2017"/>

in the `head' table.


Werner

[Hin-Tak Leung]

Post by Werner LEMBERG
I've downloaded the working Lohit Devanagari font from
  https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ;
it has
  <modified value="Wed Apr 26 10:34:57 2017"/>
in the `head' table.

Okay, mine says 14 Feb 2018. Then I went to fedora's build farm to see how/what exactly have they done to it... Apparently the ttf fedora shipped is built from sfd and fea with fontforge, then hinted with ttfautohint. So they like to build the ttf from source sfd/fea - that's fine - then run ttfautohint, which happens to be buggy .
I see the current version of ttfautohint is 1.8.2, and 1.8.1 is only 10 months old . 1.8.1 is what fedora ships and likely the one which built  lohit-devanagari :-(

[Werner LEMBERG]

Post by Werner LEMBERG
I've downloaded the working Lohit Devanagari font from
  https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ;
it has
  <modified value="Wed Apr 26 10:34:57 2017"/>
in the `head' table.

Okay, mine says 14 Feb 2018. Then I went to fedora's build farm to
see how/what exactly have they done to it... Apparently the ttf
fedora shipped is built from sfd and fea with fontforge, then hinted
with ttfautohint. So they like to build the ttf from source sfd/fea
- that's fine - then run ttfautohint, which happens to be buggy .
I see the current version of ttfautohint is 1.8.2, and 1.8.1 is only
10 months old . 1.8.1 is what fedora ships and likely the one which
built  lohit-devanagari :-(

Uh, oh. It's a regression in ttfautohint – version 1.7 works fine,
version 1.8 and higher fails. Now fixed in git. Attached is a new
version of Lohit Devanagari hinted with the current version of
ttfautohint.

So: Thanks for the report :-)


Werner

[Werner LEMBERG]

Uh, oh. It's a regression in ttfautohint – version 1.7 works fine,
version 1.8 and higher fails. Now fixed in git.

This explains why Fedora 27 with ttfautohint 1.7 was fine: dots were
there but sometimes distorted.

Yep.

I wonder if such short stems should ever be hinted. Autohinter
leaves them alone.

Older Windows rasterizers definitely need that...


Werner

[Hin-Tak Leung]

Uh, oh.  It's a regression in ttfautohint – version 1.7 works fine,
version 1.8 and higher fails.  Now fixed in git.

Thanks for all the work! I am glad we get to the bottom of this :-). It explains too why ghostscript fails but mupdf works, from the same-ish group of people - I think mupdf ignores hinting instructions.
Btw, been wondering if something could/should be done on freetype too - whIle we know where the broken hinting instructions came about in this case, similar problem can come from a different source too.

[Werner LEMBERG]

Post by Hin-Tak Leung
Btw, been wondering if something could/should be done on freetype
too - while we know where the broken hinting instructions came about
in this case, similar problem can come from a different source too.

People can always run the hinter in paranoid mode, rendering a glyph
without hinting if an error is returned...


Werner

[Derek B. Noonburg]

On Sun, 07 Oct 2018 21:42:19 +0200 (CEST)

Post by Werner LEMBERG

Post by Hin-Tak Leung
Btw, been wondering if something could/should be done on freetype
too - while we know where the broken hinting instructions came about
in this case, similar problem can come from a different source too.

People can always run the hinter in paranoid mode, rendering a glyph
without hinting if an error is returned...

Can you elaborate on this? How does one run the hinter in paranoid
mode? I'm wondering if it would be possible/useful to do this in Xpdf
(or at least provide an option to do it).

- Derek

[Werner LEMBERG]

Post by Derek B. Noonburg

Post by Werner LEMBERG
People can always run the hinter in paranoid mode, rendering a
glyph without hinting if an error is returned...

Can you elaborate on this? How does one run the hinter in paranoid
mode? I'm wondering if it would be possible/useful to do this in
Xpdf (or at least provide an option to do it).

Use FT_LOAD_PEDANTIC.


Werner

[Derek B. Noonburg]

On Wed, 10 Oct 2018 12:17:37 +0200 (CEST)

Post by Werner LEMBERG

Post by Derek B. Noonburg

Post by Werner LEMBERG
People can always run the hinter in paranoid mode, rendering a
glyph without hinting if an error is returned...

Can you elaborate on this? How does one run the hinter in paranoid
mode? I'm wondering if it would be possible/useful to do this in
Xpdf (or at least provide an option to do it).

Use FT_LOAD_PEDANTIC.

Turns out I already had code to retry FT_Load_Glyph with hinting
disabled, so it was trivial to add FT_LOAD_PEDANTIC to the first call.


Thanks!

- Derek

[Hin-Tak Leung]

Hi,
Besides Lohit-devanagari, after fedora 29 and sat on it a bit etc, I looked at the FontVal reports and found another font (one of the other Lohit-*) with visibly broken hinting - the other one is worse as one of the glyphs is broken below about 200 ppem. Luckily there are only two, so I filed 3 bugs in total at Redhat bugzilla, one for them to patch ttfautohint, the other two for them to re-hint those two fonts. The updates are on their way.
Is ttfautohint 1.8.3 (the next one, with the fix) coming soon?
This is also the first time I acted on FontVal reports... I have decided fairly on that I cannot affect the time to look at/debate/act on individual font reports as I have about 30,000 reports the last time I counted (reports from older/newer versions of same font count as one), so I don't, as a matter of policy.
Btw, is freetype 2.9.2 (or 2.10) any time soon? Been a while since 2.9.1.
Hin-Tak

[Werner LEMBERG]

Post by Hin-Tak Leung
Is ttfautohint 1.8.3 (the next one, with the fix) coming soon?

I'll first fix FreeType w.r.t. subglyph hinting, then do a new
ttfautohint release. Expect something in early January.

Post by Hin-Tak Leung
Btw, is freetype 2.9.2 (or 2.10) any time soon? Been a while since 2.9.1.

End of December if all goes well. Alexei and I have found concensus
how to improve color handling, and we will work on that in the next
few weeks.


Werner

[Hin-Tak Leung]

Thanks. No rush!
I'll possibly find some time to tidy up the win64 debug/size_t patch and send it in before Christmas then.
Hin-Tak

Post by Hin-Tak Leung
Is ttfautohint 1.8.3 (the next one, with the fix) coming soon?

I'll first fix FreeType w.r.t. subglyph hinting, then do a new
ttfautohint release.  Expect something in early January.

Post by Hin-Tak Leung
Btw, is freetype 2.9.2 (or 2.10) any time soon? Been a while since 2.9.1.

End of December if all goes well.  Alexei and I have found concensus
how to improve color handling, and we will work on that in the next
few weeks.


    Werner

[Hin-Tak Leung]

Yes, just confirming. I could get xpdf to behave correctly by setting the environment variable:
FREETYPE_PROPERTY=truetype:interpreter-version=38
Both 35 and 40 misbehave.
BTW, this only works if your freetype is built with v38. v35 was the default before about 2.7 . FT 2.7 onwards have both v40 and v35 enabled with v40 being the default. You can only switch to v38 if your freetype was built with that particular additional option (I know my 64-bit lib is - my 32-bit freetype is left at default and cannot switch to v38 this way ).

Post by Alexei Podtelezhnikov
I was able to reproduce the missing dots with ftview in the embedded
file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL). With native
default hinter enabled, some dots are always missing with sizes less
than 57. There is no problem with autohinter or with hinting disabled.
ftview 48 RSOAVR+Lohit-Devanagari.ttf

Specifically TrueType engine v40 and v35 do the damage. v38 is fine. Nikolaus?

[Derek B. Noonburg]

On Thu, 4 Oct 2018 11:05:43 -0400

Post by Alexei Podtelezhnikov

Post by Derek B. Noonburg
Regarding the first issue (missing dots --

I was able to reproduce the missing dots with ftview in the embedded
file RSOAVR+Lohit-Devanagari.ttf (attached, they are OFL). With native
default hinter enabled, some dots are always missing with sizes less
than 57. There is no problem with autohinter or with hinting disabled.
ftview 48 RSOAVR+Lohit-Devanagari.ttf

One more confirmation -- I can get Xpdf to show the problem by changing
the zoom factor (using FreeType 2.8 or 2.9.1).

- Derek