[ft-devel] sbix originOffsetX/Y interpretation.

I was making a test sbix font where I wanted the image not to have its lower left corner at 0,0 (which seems to be what most sbix fonts do). I ended up with different results from FreeType, CoreGraphics, and DirectWrite/Edge. The specification is difficult to interpret so I opened an issue for

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

I believe that Chromium is using Skia's reported font metrics which are currently calculated at https://skia.googlesource.com/skia/+/00dcf668659ab26b8691c64a977fdd19e9e8df09/src/ports/SkFontHost_FreeType.cpp#1411 . The biggest issue is that historically (and as noted above) FT_Face would always

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea (if not 0), then sTypo (if not 0), then usWin. This is now consistent across all fonts; variable fonts do not have a different fallback order. Variable fonts will apply the MVAR deltas to whichever metrics were picked.

[ft-devel] FreeType into Chromium autoroller

At [0] there is now an autoroller from Chromium's mirror of the FreeType repository [1] into Chromium. This autoroller will normally be in dry-run mode for rolling tip of tree FreeType into Chromium, so it will run the Chromium / Blink tests against tip of tree (both Chromium and FreeType), but

Re: I'm back

One thing that's been on my mind is around releasing (and this is a fairly general observation not specific to FreeType). FreeType has generally tagged a VER-2-X-X release about once every six months and hasn't had maintained release branches. Distros (and other users) generally only update to

Re: I'm back

Responding to all the scattered bits of this thread I know something about... > Skia: https://github.com/google/skia/tree/master/third_party/freetype2 > modules: no raster1, type1, pfr, bitmapped formats > options: seems to be using the default, i.e. no subpixel rendering, no > harfbuzz, no

Re: Build system considerations

Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov a écrit : > > On Tue, May 19, 2020 at 8:09 AM Hugh McMaster > wrote: > > Is there any opportunity to avoid modifying ftoption.h directly to > > enable, say, subpixel rendering with a new build system? Carrying > > permanent patches for

Re: Vulnerability warning (CVE-2020-15999)

On Mon, Oct 19, 2020, 6:19 PM Hugh McMaster wrote: > Hi Werner, > > On Tue, 20 Oct 2020 at 09:07, Werner LEMBERG wrote: > >> >> I've just fixed a heap buffer overflow that can happen for some >> malformed `.ttf` files with PNG sbit glyphs. It seems that this >> vulnerability gets already

Re: Commit ec9b6c314dc018bbf0af4ff657fa5ff56a5bf9f7 breaks existing programs

On Wed, Jan 6, 2021, 6:35 PM Nikolaus Waxweiler wrote: > Hi! > Not sure if this is intentional or anything, but the aforementioned > commit makes programs fail to render on Fedora 33. I.e. GTK3 apps spam > the console with > > (gnome-calculator:44487): Gtk-WARNING **: 23:32:19.658: drawing

Persistent CVT writes from glyf program.

While investigating some odd behavior, I discovered that in FreeType if a TrueType glyf contains instructions which read/modify/write a CVT entry and the glyph is loaded more than once the modified values persist across calls. The persistence is in the (TT_SizeRec_) size.cvt since TT_Load_Context

Re: Persistent CVT writes from glyf program.

> > > While investigating some odd behavior, I discovered that in FreeType > > if a TrueType glyf contains instructions which read/modify/write a > > CVT entry and the glyph is loaded more than once the modified values > > persist across calls. The persistence is in the (TT_SizeRec_) > > size.cvt

Re: uninitialized value in _bdf_readstream

I can reproduce locally and surprisingly this bisects to 8ef8072ba15 "[bdf, cid, pfr, winfonts] Improve rejection of other font formats." Will take a quick look. On Wed, Dec 8, 2021, 2:32 PM Derek B. Noonburg wrote: > Valgrind is reporting an uninitialized value in _bdf_readstream for > certain

Re: uninitialized value in _bdf_readstream

I think the earlier Q commit is really the culprit here. The bisected change modified the error returned by the other modules when rejecting data, so I think that change just allowed the code to get this far. Looking into getting the fuzzer going with MemorySanitizer to catch this sort of issue,

Re: ReactOS: stack vs heap

On Fri, Sep 1, 2023, 9:45 AM Alexei Podtelezhnikov wrote: > >  > >> I will try the dynamic heap allocations for the rendering > >> buffer. This might be the largest of them, I think. In addition, > >> this should help with the rendering speed when rendering complex > >> shapes like > >>

Re: ReactOS: stack vs heap

I've been meaning for a long time to propose something like this. One (or more) of those stacks is bigger than 50KB. While most desktop apps have threads with large stacks (~xMBs) there are users that run many threads in one process and force the stack size of the threads to be small (~xxKBs) to

Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)

For testing SVG, Skia has an OT-SVG testing font. [0] This font is more or less a reconstruction from the examples in the Open type specification. However, it also does interesting things with the em and view box to ensure those are handled correctly. [0]