Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Wed, 10 Oct 2018 12:17:37 +0200 (CEST) Werner LEMBERG wrote: > >> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
>> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Sun, 07 Oct 2018 21:42:19 +0200 (CEST) Werner LEMBERG wrote: > > 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
> 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. I wonder if such short stems should ever be hinted. Autohinter leaves them alone. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
>> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
>> I've downloaded the working Lohit Devanagari font from >> >> https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ; >> >> it has >> >> >> >> 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 Lohit-Devanagari.new.ttf.xz Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Friday, 5 October 2018, 05:12:22 GMT+8, Werner LEMBERG wrote: > I've downloaded the working Lohit Devanagari font from > https://releases.pagure.org/lohit/lohit-devanagari-ttf-2.95.4.tar.gz ; > it has > > 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 :-( ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
>> 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 in the `head' table. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Friday, 5 October 2018, 01:38:49 GMT+8, Werner LEMBERG wrote: > 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Thu, 4 Oct 2018 11:05:43 -0400 Alexei Podtelezhnikov wrote: > > > Regarding the first issue (missing dots -- > > > FontVal-TypoLabs2018.pdf page 73 / FontVal-x.pdf page 1): > > 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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... On Friday, 5 October 2018, 01:38:49 GMT+8, Werner LEMBERG wrote: >> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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 ). On Friday, 5 October 2018, 00:06:13 GMT+8, Alexei Podtelezhnikov wrote: > 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? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
>> 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
> 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? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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. On Thursday, 4 October 2018, 23:06:10 GMT+8, Alexei Podtelezhnikov wrote: > > Regarding the first issue (missing dots -- FontVal-TypoLabs2018.pdf > > page 73 / FontVal-x.pdf page 1): 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
> > Regarding the first issue (missing dots -- FontVal-TypoLabs2018.pdf > > page 73 / FontVal-x.pdf page 1): 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 RSOAVR+Lohit-Devanagari.ttf Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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 + (UTC) Hin-Tak Leung 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 > 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 + (UTC) > Hin-Tak Leung 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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 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 + (UTC) Hin-Tak Leung 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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 + (UTC) Hin-Tak Leung 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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
