Re: Strange hinting of precomposed character

[Patrick Lam]

Yes, all that would be good.

I think that Behdad had mentioned it at some point with the fonttools
maintainers, but this is all quite a long time ago now.

pat

On Wed, Jul 19, 2023 at 11:26 PM Werner LEMBERG  wrote:
>
>
> > Yep! https://github.com/wenzhuman/fonttools
>
> Thanks.  Unfortunately, this lacks top-level documentation, AFAICS,
> describing the changes in comparison to upstream 'fonttools'.
> Additionally, the git clone uses the 'master' branch for changes,
> which is problematic.
>
> It would be great if someone could clean this up.  BTW, have you ever
> contacted the 'fonttools' maintainers and asked them whether they are
> interested in the changes?
>
>
> Werner

Re: Strange hinting of precomposed character

[Patrick Lam]

There is also a couple of masters theses:

https://uwspace.uwaterloo.ca/bitstream/handle/10012/9116/Man_Wenzhu.pdf

https://uwspace.uwaterloo.ca/bitstream/handle/10012/14262/Liu_Zeming.pdf?sequence=3=y

Happy to answer questions!

pat

On Wed, Jul 19, 2023, 7:41 PM Brad Neimann  wrote:

> A long time ago I had some grad students write a compiler
> infrastructure for TrueType bytecode. Maybe it's mostly bit-rotted,
> but if someone were interested in working on this, I could try to
> help.
>
>
> When I get some time, I’d be happy to look into this. I’ve been doing some
> compiler-adjacent stuff recently (mostly type inference), and this seems
> like a very interesting application of those ideas.
>
> Regards,
> Brad
>

Re: Strange hinting of precomposed character

[Patrick Lam]

Yep! https://github.com/wenzhuman/fonttools

On Wed, Jul 19, 2023 at 5:17 PM Werner LEMBERG  wrote:
>
>
> > A long time ago I had some grad students write a compiler
> > infrastructure for TrueType bytecode.
>
> Ah, I faintly remember :-)
>
> > Maybe it's mostly bit-rotted, but if someone were interested in
> > working on this, I could try to help.
>
> Thanks.  Is this code available in a public repository?
>
>
> Werner

Re: Strange hinting of precomposed character

[Patrick Lam]

A long time ago I had some grad students write a compiler
infrastructure for TrueType bytecode. Maybe it's mostly bit-rotted,
but if someone were interested in working on this, I could try to
help.

pat

On Wed, Jul 19, 2023 at 2:59 AM Brad Neimann  wrote:
>
> Ah, I forgot about TrueType bytecode. Indeed, that would be challenging…
>
> Regards,
> Brad
>
>

Re: [ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType

[Patrick Lam]

Hi Armin,

On Tue, Jul 10, 2018 at 1:04 PM,   wrote:
> Does anyone know font geeks?
> ===
>
> If possible, I would love to ditch the "old" corpus since its fonts are huge
> (they are proper fonts) and repetitive (not exactly the initial fuzz corpus
> of your dreams).  While I do know more/less exactly what the perfect fuzzing
> fonts should look like, I would much rather spend my time improving and
> expanding the fuzz targets than creating those fonts.  So, if there are any
> font enthusiasts listening (or if you know any people who would love doing
> that) please step forward; that would really be a great help :)
>
> Ben (bungeman) already did a great job in providing a base set of sample
> fonts that are optimised for fuzzing (small fonts, few glyphs, concentrating
> on a few, very distinctive features) but there could be a lot more
> (https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora/
> truetype/bungeman etc.).
>
> For reference: I will also contact HarfBuzz and see if they have interesting
> stuff and IF they do, if they would share that with FreeType :)

My graduate student Zeming has been making good progress this term on
TTF bytecode analysis. So we don't have a corpus, but we can now
easily manipulate bytecode for existing fonts. If there's anything
specific you have in mind, we should figure out whether we can make
that happen.

pat

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] endless loops in bytecode

[Patrick Lam]

Have also seen a few (not many) on some fonts in my corpus.

On Sep 10, 2016 16:28, "Alexei Podtelezhnikov"  wrote:

>
> >  PUSHW[1]
> >-3
> >  JMPR
> >
> > The PUSHW instruction pushes one word onto the stack (value -3), which
> > is the offset JMPR is using to jump back
>
> Did you see jumps back in the real world? Can you just ignore jumps back?
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] endless loops in bytecode

[Patrick Lam]

We had initially ignored jump instructions while designing our font
analysis code. They do occur sometimes though. I'd go with a blacklisting
approach on a per-font level (maybe per glyph?) Once someone trips the
timeout they get no more hints.

pat

On Sep 10, 2016 13:39, "Werner LEMBERG"  wrote:

>
> Folks,
>
>
> do you have any ideas how to discover endless loops in bytecode that
> don't change the nesting level?  This would be very helpful for broken
> or malicious fonts that can make bytecode interpretation very slow.
>
> There are three instructions which can cause such loops.
>
>   JMPR  (jump relative)
>   JROT  (jump relative on true)
>   JROF  (jump relative on false)
>
> All three opcodes allow negative offsets; it's not documented in the
> specification, but the MS interpreter disallows jumps to other
> functions, and so does FreeType.  Here's the simplest possible endless
> loop.
>
>   PUSHW[1]
> -3
>   JMPR
>
> The PUSHW instruction pushes one word onto the stack (value -3), which
> is the offset JMPR is using to jump back to the PUSHW position.
>
> Currently, FreeType aborts bytecode interpretation after executing one
> million instructions (this can be changed at compile time) – this
> limit holds per glyph.  I wonder whether there are any suggestions how
> to catch those three sneaky instructions earlier.
>
> My only idea up to date is to count JMPR, JROT, and JROF separately,
> using a threshold of, say, 1.  Those instructions are very rare in
> normal bytecode, and having so much jumps within a single function is
> extremely unlikely.
>
>
> Werner
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "Inside the fastest font renderer in the world" (Re: Freetype-devel Digest, Vol 139, Issue 3)

[Patrick Lam]

In case anyone is curious about Rust, I just looked into it in some
detail recently. You can program it imperatively, although it also
supports most features of functional languages. There will be less
culture shock coming from C to Rust than from C to O'Caml for sure.

As I alluded to earlier, Rust does better at memory management than C,
and the compiler enforces the memory management for you without
garbage collection and without refcounting. But everything has to have
a single owner. (This can cause some learning curve). The compiler
knows when things are no longer referenced and then deallocates them.

pat


On Thu, Aug 4, 2016 at 8:24 PM, Hin-Tak Leung
 wrote:
> I saw the post about it earlier on typedrawers. If it wasn't because of the 
> poster - Raph Levien - I'd just laugh it off. I'd usually be skeptical of 
> such a claim - because, in the end of the day, everything is machine 
> instructions, right? Shouldn't make any difference what language something is 
> written in, if your compiler is good enough. I trust Raph made a valid claim 
> though. However:
>
> - the main strength of FreeType is not speed - though it is amazingly fast. 
> the main strength is that it has had random crap thrown at it for 20+ years. 
> Doing rendering on perfectly valid and good fonts is fine, so Raph's answer 
> definitely earns its place, in the environment where Google concentrates on 
> Androids, etc - make it very fast for *selected good* fonts. Random crap 
> fonts? Don't know how adding error recovery etc slows down the new solution 
> yet.
>
> - the exotic language Rust. Finding people to maintain/contribute code 
> written in a niche language (and quite an unusual one as that) is hard. It 
> may bit-rot if the origin owner loses interests.
>
> It is hard enough to find people to contribute to the font validator, which 
> is in C#, rather common in windows land; and C# is close enough to both Java 
> and C, etc. Rust I heard is similar to Objective Caml, which is in turn 
> similar to haskell... (I heard!).
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction and stem darkening

[Patrick Lam]

JROT: yes, none of the Noto fonts use it, but other fonts do. The
right way to support it in a bytecode analysis tool is probably to
rewrite the bytecode to not use it. There is partial support for JROT
right now, but it is not complete.

Regeneration of TrueType bytecode should be fairly straightforward; it
just requires some development resources.

As I have time I've been going through the code and refactoring it, etc.

pat


On Tue, Jan 19, 2016 at 4:31 PM, Behdad Esfahbod
<behdad.esfah...@gmail.com> wrote:
> [+Patrick Lam]
>
> On 16-01-19 04:16 PM, Werner LEMBERG wrote:
>>
>>>> I think it *is* possible.  The method, as implemented by
>>>> Toshiya-san, compares various SFNT table checksums.  Among them is
>>>> the `cvs ' table, and modifying this table is essentially
>>>> impossible without interpreting and changing the bytecode.  Ditto
>>>> for `fpgm'.  I dare to say that even a subsetted font with a single
>>>> glyph contains the original `cvs ' and `fpgm' tables unmodified,
>>>> which should enable FreeType to discover its trickyness.
>>>
>>> Note that this will eventually change ;).
>>>
>>>   https://github.com/behdad/fonttools/issues/446
>>
>> Interesting.  Reading the thesis (from 2014) I see that they don't
>> mention ttfautohint, which really suprises me.  It also says that some
>> instructions like JROT[] aren't supported because they couldn't find
>> fonts that use it.  Well, fonts auto-hinted with ttfautohint *do* use
>> it :-)  [It seems that the git repository has added support meanwhile.]
>>
>> Of course, the most difficult part IMHO is the regeneration of
>> TrueType code,
>
> I wouldn't say it's the most difficult part.  But yes, it's not implemented so
> far.
>
>
>>  which is not covered in the thesis.  Has this been
>> implemented meanwhile?  There is no real documentation of the code in
>> the git repository...
>
> Let's discuss it on the github issue:
>
>   https://github.com/behdad/fonttools/issues/446

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel