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 w
>> 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
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
> 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
On Saturday, 6 October 2018, 17:18:08 GMT+8, Werner LEMBERG
wrote:
>> 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 ghos
> 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 th
>> 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. Autohin
>> 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
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'
>> 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
> r
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
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,
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...
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
>> 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. f
> 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
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
> > 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 miss
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.
W
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 transparen
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
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
custom
22 matches
Mail list logo
