Re: The current state of rendering and overlap

Note that freetype does not use the overlap flags to determine the path fill rule (winding vs even-odd), it always uses winding for TT or CFF2 variable fonts, as the spec mandates; the discussion here is about freetype using the (TT glyf only) overlap flags to enable what Alexei calls "4x4 bilevel

Re: The current state of rendering and overlap

Hey Skef, This thread might be of interest to you https://github.com/fonttools/fonttools/issues/2059 On Tue, Dec 19, 2023 at 10:58 AM Skef Iterum wrote: > I'm afraid I don't have an exact overlap-less example handy because the > equivalent static font also hints a bit differently, hiding the

Re: 6th OT-SVG hook bridge (Re: skia as a shared library, and the (poor) support for Google's OT-SVG variant by libre software

Hin-Tak, the OT-SVG fonts which are built by the nanoemoji color font compiler are, to the best of my knowledge, up to spec (I mean, the OpenType SVG table specification). The SVG documents embedded in the OpenType SVG table are *not* supposed to be simply extracted to an .svg text file and then

Re: Skia-based ot-svg renderer hook to freetype

orge.net> wrote: > > > > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo < > cos...@anthrotype.com> wrote: > > > > Hin-Tak, what do you mean by "Google OT-SVG fonts"? They're only one > OT-SVG format. > > > Yes and no. I don't have th

Re: Skia-based ot-svg renderer hook to freetype

Hin-Tak, what do you mean by "Google OT-SVG fonts"? They're only one OT-SVG format. On Tue, 4 Jul 2023, 19:15 Hin-Tak Leung, wrote: > (Cross-posted to freetype-devel) > > It seems that skia itself has all the rsvg equivalent to implement the > ot-svg renderer callback hooks in freetype, but

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

I was wrong :-). > > On Wednesday, 24 May 2023 at 21:16:54 GMT+8, Cosimo Lupo < > cos...@anthrotype.com> wrote: > > > if you downloaded that font from > https://fonts.google.com/specimen/Aref+Ruqaa+Ink then it's a font bug, or > rather the font has been incorrectly subse

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

if you downloaded that font from https://fonts.google.com/specimen/Aref+Ruqaa+Ink then it's a font bug, or rather the font has been incorrectly subsetted (the rest of the font lost a couple unreferenced glyphs but SVG table stayed the same because hb-subset can't subset it; it should have been

Re: test font with both SVG and COLR table

or font flavors, the market acceptance was low (but > still, people have made many such fonts). But as soon as those flavors are > down to just 2, I think both will stick around. (Though I do see a reason > for sbix to also exist, especially in Apple’s own HEIC flavor, not PNG, > which the

Re: test font with both SVG and COLR table

Hi Werner and all, please find attached a test COLRv1 + SVG font, containing only one color glyph ✍ "WRITING HAND" (U+270D) emoji. The font was built using nanoemoji using the following command, from the root of the noto-emoji

Re: [ft-devel] ttfautohintGUI - Command not found.

LGTM, thanks! Il 8 feb 2019, 14:33 +0100, Werner LEMBERG , ha scritto: > > > homebrew no longer supports build options, so in order to build > > ttfautohint with GUI with homebrew we had to make a separate, custom > > formula which is not hosted on the homebrew-core (upstream) repo, > > but on a

Re: [ft-devel] ttfautohintGUI - Command not found.

Hi Martin, homebrew no longer supports build options, so in order to build ttfautohint with GUI with homebrew we had to make a separate, custom formula which is not hosted on the homebrew-core (upstream) repo, but on a so-called Homebrew Tap (i.e. a user's github repository). The

Re: [ft-devel] Integrating Docwriter into FreeType

current or future projects. -- Cosimo Lupo Il 29 lug 2018, 11:28 +0200, Nikolaus Waxweiler , ha scritto: > > > (1) Add a check for (a) `python', (b) `pip', and (c) `docwriter' in > > FreeType's `configure' script. > > I meant, if you go the PyPI route, you don’t need to check for

Re: [ft-devel] `make refdoc-venv' fails

Alternatively instead of sourcing the venv, the refdoc target can call the docwriter.py script using the python interpreter that is inside the virtual environment, since you know the exact path to it as refdoc-venv has created it. -- Cosimo Lupo Il 29 lug 2018, 08:28 +0200, Werner LEMBERG , ha

Re: [ft-devel] `make refdoc-venv' fails

That’s because it’s still using the global python environment to run docwriter.py, it the virtual one. The latter environment needs to be sourced before it is activated. -- Cosimo Lupo Il 29 lug 2018, 08:28 +0200, Werner LEMBERG , ha scritto: > > Nikhil, > > > `make refdoc-ve

Re: [ft-devel] Integrating Docwriter into FreeType

environment, instead of relying on a mixture of pip-installed packages and others provided by the distro package manager. On Fri, Jul 27, 2018 at 12:17 PM Cosimo Lupo wrote: > Besides, the `--user` option of pip install is incompatible with a virtual > environment, you should remove that in an

Re: [ft-devel] Integrating Docwriter into FreeType

, that you shouldn't force a user to permanently modify their global or user's environment just in order to build the documentation. On Fri, Jul 27, 2018 at 12:14 PM Cosimo Lupo wrote: > It's not a good idea to have the `make refdoc` target call pip to install > missing requirements in the user's

Re: [ft-devel] Integrating Docwriter into FreeType

ome/wl/.local/lib/python2.7/site-packages/mkdocs/theme.py", line > 77, in _load_theme_config > theme_dir = utils.get_theme_dir(name) > File > "/home/wl/.local/lib/python2.7/site-packages/mkdocs/utils/__init__.py", > line 3

Re: [ft-devel] [ft] Announcing ttfautohint 1.8.2

Thanks -- Cosimo Lupo Il 24 lug 2018, 19:50 +0100, Werner LEMBERG , ha scritto: > > > I just tried to do `git pull` from the > > http://repo.or.cz/ttfautohint.git repository and I cannot find the > > current v1.8.2 tag. Did you forgot to push it maybe? > > Oops! Now p

Re: [ft-devel] [ft] Announcing ttfautohint 1.8.2

ttfautohintGUI with homebrew on the Mac works > again. > > * Bug fix: Point deltas didn't work for composite glyphs. > > ___ > Freetype mailing list > freet...@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype > -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] `brew install --with-qt ttfautohint` fails

That’s great, thanks Werner! -- Cosimo Lupo Il 24 lug 2018, 09:11 +0100, Werner LEMBERG , ha scritto: > > > > The build fails with a configure error: > > > > > > configure: error: > > > Calling /usr/local/opt/qt/bin/qmake -spec macx-g++ failed. > &

Re: [ft-devel] `brew install --with-qt ttfautohint` fails

Perfect! I think the only thing that’s left is updating the ttfautohint formula to set the QMAKESPEC environment variable to use clang instead of g++. -- Cosimo Lupo Il 21 lug 2018, 16:35 +0100, Werner LEMBERG , ha scritto: > > > Please try this regexp. > > > > > > '/

Re: [ft-devel] `brew install --with-qt ttfautohint` fails

yes, I just tried that with the default mac /usr/bin/sed and it's working! On Sat, Jul 21, 2018 at 4:18 PM, Werner LEMBERG wrote: > > > /usr/local/opt/qt/bin/qmake --version 2>&1 | > > /usr/local/opt/gnu-sed/libexec/gnubin/sed > > '/^.*\([0-9]\+\.[0-9]\+\.[0-9]\+\).*$/!d;s//\1/' > > Please try

Re: [ft-devel] `brew install --with-qt ttfautohint` fails

Thanks Werner! I've updated the formula to set the QMAKESPEC environment variable to "macx-clang" instead of patching m4/autoroll.m4 same link as before: https://gist.github.com/anthrotype/77c58ccb4383b8b1545800bf6fd38732 Yes, it's weird that it only works with GNU sed. This is the command

[ft-devel] `brew install --with-qt ttfautohint` fails

Hi Werner and all, as others may have noticed, e.g. see https://discourse.brew.sh/t/trouble-installing-ttfautohint/2084, it is currently impossible to successfully `brew install --with-qt ttfautohint`, at least on the latest macOS 10.13.6 and up-to-date homebrew. The build fails with a configure

Re: [ft-devel] ttfautohint without freetype-config script (Re: Freetype-devel Digest, Vol 156, Issue 10)

Wed, 10 Jan 2018 11:17:26 +0000 > > From: Cosimo Lupo <cos...@anthrotype.com> > > To: Werner LEMBERG <w...@gnu.org> > > Cc: freetype-devel@nongnu.org > > Subject: Re: [ft-devel] build > > ttfautohint without freetype-config > > script > > >

Re: [ft-devel] build ttfautohint without freetype-config script

ETYPE_LIBS directly on the configure command line. Let me know if this is what you had in mind, thanks. C. On Tue, Jan 9, 2018 at 7:31 PM Cosimo Lupo <cos...@anthrotype.com> wrote: > Makes sense, I’ll do that. > > Il 9 gen 2018, 19:22 +, Werner LEMBERG <w...@gnu.org&

Re: [ft-devel] build ttfautohint without freetype-config script

Makes sense, I’ll do that. Il 9 gen 2018, 19:22 +, Werner LEMBERG , ha scritto: > > > autoconf is not my cup of tea, but I've tried anyway. See the patch > > attached below. > > Thanks! However, this is not exactly what I had in mind – and sorry > for not telling you earlier: If

Re: [ft-devel] build ttfautohint without freetype-config script

stuff... > > > That would allow me to use cmake at least for building freetype (and > > harfbuzz). For ttfautohint itself, that's more complicated because > > of gnulib (I've asked on the cmake mailing list for help). > > Yes. gnulib is very tightly tied to bot

[ft-devel] build ttfautohint without freetype-config script

more complicated because of gnulib (I've asked on the cmake mailing list for help). Thank you, Cosimo -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

I was able to run make dist by applying the patch attached below. Basically, some of the doc targets were still looking for the ttfautohint.h inside the src/lib folder instead of the build/lib folder. On Fri, Dec 22, 2017 at 11:26 AM Cosimo Lupo <cos...@anthrotype.com> wrote: >

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

ohint with the shared library support? > > I hope in the end of December. > > > Werner > -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake (Re: Freetype-devel Digest, Vol 155, Issue 12

; > Date: Wed, 13 Dec 2017 11:51:47 +0000 > From: Cosimo Lupo <cos...@anthrotype.com> > To: Werner LEMBERG <w...@gnu.org> > Cc: martin.giesek...@uos.de, > freetype-devel@nongnu.org > Subject: Re: [ft-devel] Fwd: buiding > ttfautohint with cmake? > >

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

collaborator on the repo > > Thanks, but no. At least not yet :-) > > > Werner > -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

oops, wrong link (that's my fork where I work from) This is the upstream repository of ttfautohint-py https://github.com/fonttools/ttfautohint-py On Thu, Dec 14, 2017 at 5:48 PM Cosimo Lupo <cos...@anthrotype.com> wrote: > Thank you Werner! > I tested them in my ctypes wrapper (both

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> > routines > > Two fields `alloc-func' and `free-func' are now added to the git > repository. The corresponding code is untested yet, so please check > whether it works correctly! > > > Werner > -- Cosimo Lupo ___ Fr

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

;> pointers to allocation rountines, right? > > > > no, as long as TTF_autohint_done frees them. unless the user is > > also expected to re-allocate them > > There are high chances that the user has to re-allocate them – > usually, information gets added to the

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

gt; `TA_Info_Post_Func' expects that the user modifies entries allocated > with `malloc'. For such cases I guess we actually *need* function > pointers to allocation rountines, right? > > > Werner > -- Cosimo Lupo ___ Freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

IMO, what matters is not which specific memory allocator/deallocator is used (whether the defaults, or user provided ones), but that they match with one another (they are defined by the same library). That’s why I like the simplicity of a TTF_autohint_done function. That’s just a one liner.

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

gt; and the caller for garbage collection stuff and the like, but maybe >> I'm completely wrong... >> >> Any other opinions? >> > >> >> Werner >> >> _______ >> Freetype-devel mailing list >> Freetype-d

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

at memory. > > What do you think about providing function pointers to TTF_autohint > for memory allocation and deallocation instead? > > > Werner > -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

/python/1019748 In general a DLL where memory gets allocated should also provide a function to free that memory. Thank you in advance Cheers On Sun, Dec 10, 2017 at 5:19 PM Cosimo Lupo <cos...@anthrotype.com> wrote: > Thanks Werner for merging Martin's patch into upstream! > > Marti

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

ry that returns the current > ttfautohint version, e.g. "1.7"? Maybe something simple like this: > > TA_LIB_EXPORT const char* > TTF_autohint_version() > { >return VERSION; > } > > Martin > -- Cosimo Lupo ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Fwd: buiding ttfautohint with cmake?

d freetype. Thank you very much Martin and Werner for the assistance. Cheers -- Forwarded message ------ From: Cosimo Lupo <cos...@anthrotype.com> Date: Sat, Dec 9, 2017 at 2:38 PM Subject: Re: [ft-devel] buiding ttfautohint with cmake? To: Martin Gieseking <martin.giesek...@uos.

Re: [ft-devel] buiding ttfautohint with cmake?

braries. > > Martin > > > Am 08.12.2017 um 22:44 schrieb Cosimo Lupo: > > Hi Martin, > > > > early on you wrote > > > > >  it shouldn't be too complicated to build a DLL of ttfautohint that > > statically links all dependencies, e.g. using dlltool. &g

Re: [ft-devel] buiding ttfautohint with cmake?

imo On Fri, Dec 8, 2017 at 1:07 PM Cosimo Lupo <cos...@anthrotype.com> wrote: > Thanks Martin! It works well :) > > Werner, would it be possible to merge this patch upstream, so that I can > use it without having to apply this downstream? > I think it would be useful for o

Re: [ft-devel] buiding ttfautohint with cmake?

AM Martin Gieseking <martin.giesek...@uos.de> wrote: > Am 08.12.2017 um 02:27 schrieb Cosimo Lupo: > > P.S. It’s Cosimo btw ;) > > Oops, just noticed the typo. Sorry for that. It wasn't intentional. > > Let me know if you have any issues with the the buil

Re: [ft-devel] buiding ttfautohint with cmake?

e target applications. However, it shouldn't be too complicated to > build a DLL of ttfautohint that statically links all dependencies, e.g. > using dlltool. > > Martin > > > Am 07.12.2017 um 16:51 schrieb Cosimo Lupo: > > Thanks Werner, > > > > I looked at

Re: [ft-devel] buiding ttfautohint with cmake?

for more information on the > used modules. > > The idea of gnulib is that it only provides replacement code if the > host's functionality is either missing, incomplete, or buggy. These > tests are implemented as M4, to be automatically integrated into > automake an

[ft-devel] buiding ttfautohint with cmake?

Hello freetype-devel, I would like to make a Python wrapper for ttfautohint, to use it for our fontmake font building pipeline. I don't want to call the native ttfautohint executable as a subprocess. I want to build a shared library (.so, .dll, .dylib) and call that from Python using either

Re: [ft-devel] rendering mode of Firefox on Windows 10

Have you tried forcing Direct2D by setting "gfx.direct2d.force-enabled" to "true"? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] RasterInfo.ttf

This is really useful. I was exactly looking for something like that! Thank you, Werner! On Tue, Oct 6, 2015 at 8:42 PM, Werner LEMBERG wrote: > I guess you might enjoy this :-) > http://freetype.org/freetype2/docs/rasterinfo/rasterinfo.html > Werner >

Re: [ft-devel] max_instructions in ttfautohint

on the matter. Let’s see what people from MS have to say. Thanks again, Cosimo -- Cosimo Lupo, Font Design, Dalton Maag Ltd 9th Floor, Blue Star House, 234-240 Stockwell Road, London, SW9 9SP, UK Mobile: +44 7825 324360 London Office: +44 20 7924 0633 Registered office: Mutfords, Hare Street

[ft-devel] max_instructions in ttfautohint

recalculating the maxp's maxSizeOfInstructions. Therefore I'm wondering what the correct value shoud be? Btw, there's also an open pull request on Behdad's fonttools about this issue: https://github.com/behdad/fonttools/pull/274 Thank you, Cheers -- Cosimo Lupo

Re: [ft-devel] max_instructions in ttfautohint

is that a rethoric question? ;-) -- Cosimo Lupo, Font Design, Dalton Maag Ltd 9th Floor, Blue Star House, 234-240 Stockwell Road, London, SW9 9SP, UK Mobile: +44 7825 324360 London Office: +44 20 7924 0633 Registered office: Mutfords, Hare Street, Buntingford, SG9 0ED, UK Registered

Re: [ft-devel] GX support now working

Hello Werner and all, I’m among those developers “craving” for a tool to create test fonts, specifically to write unit tests for fontTools. I checkout out the 010 Editor and the “TTFTemplate.bt you linked to. It doesn’t look much different from what the sstruct.py and sfnt.py modules already