suzuki toshiya | 16 May 15:15 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

Oh, I slipped to mention a change from my patch in previous
post and committed one. In previous post in this list, I added
a public function FT_List_GetNodeAt(). But, now I moved it into
ttgload.c, as a private function. It is just because once we
publish some function, we cannot withdraw it. If there is a
better place to include the internal utility functions, I will
do so.

Regards,
mpsuzuki

suzuki toshiya wrote:
> Dear Werner,
> 
> Just I've committed the simpler patch.
> 
> Reading your comment carefully, "might not be working with the
> platform whose default pointer is less than 32-bit" was already
> commented :-).
> 
> Maybe just 16-bit compiler would not be sufficient, the compilers
> supporting Intel tiny/small/medium memory model should be used
> to check what will happen. Watcom compiler could be a candidate.
> But please let me work for this issue in later...
> 
> Regards,
> mpsuzuki
> 
(Continue reading)

suzuki toshiya | 16 May 15:22 2016
Picon

Re: [ft] Glyph 0xBB does not load from TTF-FreeFont FreeSerif.ttf since 6.12.2

Dear Volker,

Thank you for reporting, your issue seems to be same with
the issue discussed in "Failure in loading U+033F in DejaVu fonts".

I think the latest git head fixes this issue. If possible,
please test. I tested by myself and the issue seems to be
fixed.

Regards,
mpsuzuki

Volker Schatz wrote:
>     Hello,
> 
> I am using freetype in a personal fork of the text/graphical links browser and
> have the following issue since a few months ago.
> 
> As of version 6.12.2, a single glyph from FreeSerif.ttf (from
> http://www.nongnu.org/freefont/) cannot be loaded any more, namely code point
> 0xBB (">>", guillemotright).
> 
> This small program demonstrates the problem:
> http://volkerschatz.com/tmp/freetype2-0xBB.c
> With my current freetype version, 6.12.3, it fails, but when LD_PRELOADing
> version 6.12.1, it succeeds.  As far as I can tell, the problem occurs only
> with FreeSerif.ttf and only with glyph 0xBB.
> 
> The error code is 0x15, "invalid composite glyph".  As far as I can see with
> fontforge, this looks like a composite glyph, as each of the ">" angles has a
(Continue reading)

suzuki toshiya | 16 May 15:08 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

Just I've committed the simpler patch.

Reading your comment carefully, "might not be working with the
platform whose default pointer is less than 32-bit" was already
commented :-).

Maybe just 16-bit compiler would not be sufficient, the compilers
supporting Intel tiny/small/medium memory model should be used
to check what will happen. Watcom compiler could be a candidate.
But please let me work for this issue in later...

Regards,
mpsuzuki

Werner LEMBERG wrote:
>> I updated the simplest fix in my hand.  I was going to commit it to
>> head of git repository, but savannah is in some network trouble.
>> Attached is the patch, but if anybody wants, I will make a "make
>> dist" tarball which is ready to "./configure && make".  please let
>> me know.
> 
> Savannah seems to be back, so please proceed!
> 
>> Also I have more complex patch using same strategy but do not rely
>> on arbitrary usage of GID.  I think the current patch would work on
>> the platforms whose default pointer is 32-bit.  For the platform
>> whose default pointer is 16-bit or shorter, some fonts having 64k
>> glyphs can confuse the simplest fix.
(Continue reading)

Volker Schatz | 16 May 14:01 2016

[ft] Glyph 0xBB does not load from TTF-FreeFont FreeSerif.ttf since 6.12.2

    Hello,

I am using freetype in a personal fork of the text/graphical links browser and
have the following issue since a few months ago.

As of version 6.12.2, a single glyph from FreeSerif.ttf (from
http://www.nongnu.org/freefont/) cannot be loaded any more, namely code point
0xBB (">>", guillemotright).

This small program demonstrates the problem:
http://volkerschatz.com/tmp/freetype2-0xBB.c
With my current freetype version, 6.12.3, it fails, but when LD_PRELOADing
version 6.12.1, it succeeds.  As far as I can tell, the problem occurs only
with FreeSerif.ttf and only with glyph 0xBB.

The error code is 0x15, "invalid composite glyph".  As far as I can see with
fontforge, this looks like a composite glyph, as each of the ">" angles has a
caption "guilsinglright" attached.  But the same goes for 0xAB (guillemotleft),
which loads OK with the current freetype library.  I do not have the tools to
investigate the font file further.

Should I file a bug report for freetype, am I doing something wrong, or is it a
bug in FreeSerif.ttf?

Thanks in advance for any help.

Volker

PS: I am using Arch Linux.  System details:
$ uname -a
(Continue reading)

suzuki toshiya | 15 May 04:38 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Khaled,

Thank you for providing another example. It seems that
oriya.ttf is really including a recursive reference
(gid=8 refers gid=64 & gid=8).

I updated the simplest fix in my hand. I was going to
commit it to head of git repository, but savannah is
in some network trouble. Attached is the patch, but
if anybody wants, I will make a "make dist" tarball
which is ready to "./configure && make". please let me
know.

Also I have more complex patch using same strategy but
do not rely on arbitrary usage of GID. I think the
current patch would work on the platforms whose default
pointer is 32-bit. For the platform whose default pointer
is 16-bit or shorter, some fonts having 64k glyphs can
confuse the simplest fix.

Regards,
mpsuzuki

Khaled Hosny wrote:
> On Tue, May 10, 2016 at 08:32:48PM +0900, suzuki toshiya wrote:
>> Dear Werner,
>>
>>> Should I consider overwriting (and extend if required)
>>> storategy, to minimize the memory management?
>> If we can assume the recurse_count in load_truetype_glyph()
(Continue reading)

suzuki toshiya | 10 May 13:32 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

> Should I consider overwriting (and extend if required)
> storategy, to minimize the memory management?

If we can assume the recurse_count in load_truetype_glyph()
is always incrementally changed, it is possible to use
the index of the node to record the recurse_count.
This assumption reduces the size of the patch.

To reduce the repeated allocation & freeing the node,
I fill the unused nodes by gid = -1.

Regards,
mpsuzuki

Attachment (mps20160510-1900.diff): text/x-patch, 4430 bytes
_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
suzuki toshiya | 10 May 08:30 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

The naming convention for the types, variables and functions
need further improvement (sorry for my poor English), and some
compiler warnings should be fixed, but anyway I've drafted
a proof of concept. I confirmed it does not complain DejaVu
but detects the recursive reference in the sample files in
bug #46372.

--

please think about the glyph composed like this.

a-+-b-c-d-e
  +-f-g

in following, I note the node as a:0, the first "a" is
the glyph id, the second "0" is the recursion count.

now, the component is "pushed" to the list.

after parsing the first chain, composites would be like:
[ e:4, d:3, c:2, b:1, a:0 ]

when we push the first node in the 2nd chain, f:1,
the list is rotated until the node whose recursion count
is less than "1" (of f:1). For this rotation, I introduced
FT_List_Down().

the rotated result is
(Continue reading)

suzuki toshiya | 10 May 05:53 2016
Picon

[ft] wip: looped reference detection (Re: Failure in loading U+033F in DejaVu fonts)

Dear Werner,

The original detection was sufficient for the case:

the composition tree is something like
a-+-b-c-b
  +-d
  +-e

the composites list would be "a-b-c-b-d-e", and it can
detect the loop at the 2nd occurrence of b.

In DejaVu case, the structure is

a-+-b
  +-b

and the composites list would be "a-b-b", and
it can confuse the detector at the 2nd occurrence of b.

Just I've scratched an idea as attached one;
* record both of gid & recursion count into loader->composites.
* if same gid is found at the earlier recursion count, it is recognized as loop.

the composites list for the former case would be
"a:1 - b:2 - c:3 - b:4 - d:2 - e:2", we can detect the loop
by the existence of "b:2" and "b:4".
the composites list for the latter case would be
"a:1 - b:2 - b:2", we can expect that it is repeated but not looped.

(Continue reading)

suzuki toshiya | 10 May 04:19 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Hi,

It seems that the changeset 758d55e522eb426dad2f15adc1d945f7896d7b29
(between 2.6.1 and 2.6.2) is the point that FT2 starts the complain
against DejaVu. The changset was introduced to detected looped reference.

Checking TTX disassmbler output, DejaVu font has no looped reference
for U+033F.

uni033F refers uni203E twice

    <TTGlyph name="uni033F" xMin="-1044" yMin="1082" xMax="20" yMax="1547">
      <component glyphName="uni203E" x="-1024" y="0" flags="0x1004"/>
      <component glyphName="uni203E" x="-1024" y="-322" flags="0x1004"/>
    </TTGlyph>

uni203E refers "underscore"
    <TTGlyph name="uni203E" xMin="-20" yMin="1404" xMax="1044" yMax="1547">
      <component glyphName="underscore" x="0" y="1887" flags="0x1004"/>
    </TTGlyph>

"underscore" is self-standing.

    <TTGlyph name="underscore" xMin="-20" yMin="-483" xMax="1044" yMax="-340">
      <contour>
        <pt x="1044" y="-340" on="1"/>
        <pt x="1044" y="-483" on="1"/>
        <pt x="-20" y="-483" on="1"/>
        <pt x="-20" y="-340" on="1"/>
      </contour>
(Continue reading)

Khaled Hosny | 10 May 01:59 2016
Gravatar

[ft] Failure in loading U+033F in DejaVu fonts

I just noticed that FreeType 2.6.3 (didn’t try older versions), fails to
load the glyph for U+033F in all DejaVu fonts. Trying with ftview:

$ FT2_DEBUG="any:2" ftview -m "̿" 100 DejaVuSans.ttf

I get an infinite loop of:

TT_Load_Glyph: glyph index 752
TT_Load_Composite_Glyph: infinite recursion detected

I “think” the code in question src/truetype/ttgload.c:1653 is confused
by the fact that the two components refer to the same glyph, as I don’t
see where is the infinite recursion. But I’m not really sure, it can
very well be indeed a bug in the font. Any ideas?

Regards,
Khaled

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
qw | 27 Apr 09:13 2016

[ft] how to get text width and height in libfreetype

Hi,
ffmpeg adopts libfreetype as 'drawtext filter'.
 
In ffmpeg, 'drawtext filter' is used to put some utf-8 format text over video stream. I want to get two values, i.e. text_h and text_w, which will be used in c/c++ functions.
text_h, th

the height of the rendered text

text_w, tw

the width of the rendered text

 
How to get those two values? Does libfreetype have some interface function to fetch the two value for some input text?
Thanks!
Andrew
 


 

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Gmane