Re: Gitlab-ci? Re: Another c++ compile failure...
I think there are three reasons: - c++ compiler generally does better type checking. "Enums = ints", and "void * = (any type) *" are bad things in c, and their usage should be warned... - there is at least one library which has inter-dependence with freetype - harfbuzz, which is in c++... - we have a historical problem where ft2-demos depends on and uses freetype2's configure, without its own. The newer demos (some of them in c++, and depending on qt, etc)aren't even built by default / together with the older ones. I am really approaching it on a 4th reason, of using skia in ft2-demos, somewhat related to 2nd and the 3rd. At the moment, it looks as if the only option of generally supporting COLRv1 on Linux /freetype-based system is via skia; until somebody else write a COLRv1 library that interops with freetype, I guess. Decoupling ft2-demos from freetype, splitting it into "genuine demos" (using public APIs only, can work with system freetype binary library and headers) and "advanced usage" (needing freetype internals) and ft2-demos having its own configure, etc, is probably the long-term way forward... On Thursday 23 May 2024 at 06:45:26 BST, Vincent Torri wrote: hello I don't understand the interest of compiling Freetype with a c++ compiler. The source code is written in C. By convention, CC is usually for C compilers. To compile C++ code, CXX env var should be used, not CC best regards Vincent Torri On Thu, May 23, 2024 at 3:16 AM Alexei Podtelezhnikov wrote: > > Hi Hin-Tak, > > These macros were never used before. I fixed them. Now I think they > made the code less readable and I might revert to the old code. > > Thanks, > Alexei > > On Wed, May 22, 2024 at 6:12 PM Hin-Tak Leung > wrote: > > > > Actually it might be a good idea to stick CC=g++/clang++ as an additional > > job in .gitlab-ci.yml ? I mean, it already does gcc and clang. > > > > On Wednesday 22 May 2024 at 23:05:47 BST, Hin-Tak Leung > > wrote: > > > > > > Should be obvious - needs casting from "void *" to "unsigned char *" and > > etc... > > > > Shouldn't be too hard to see yourself with CC=c++ when building... > > > > In file included from > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:22: > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgload.c:421:14: > > error: assigning to 'FT_Byte *' (aka 'unsigned char *') from incompatible > > type 'FT_Pointer' (aka 'void *') > > 421 | if ( FT_DUP( exec->glyphIns, p, n_ins ) ) > > | ^~ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: > > note: expanded from macro 'FT_DUP' > > 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) > > | ~~^~ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: > > note: expanded from macro 'FT_MEM_DUP' > > 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), > > ) > > | ^ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: > > note: expanded from macro 'FT_MEM_SET_ERROR' > > 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) > > | ^~~~ > > In file included from > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:23: > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgxvar.c:2718:12: > > error: assigning to 'FT_MM_Var *' (aka 'FT_MM_Var_ *') from incompatible > > type 'FT_Pointer' (aka 'void *') > > 2718 | if ( FT_DUP( mmvar, ttface->blend->mmvar, > >ttface->blend->mmvar_len ) ) > > | > >^~~ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: > > note: expanded from macro 'FT_DUP' > > 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) > > | ~~^~ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: > > note: expanded from macro 'FT_MEM_DUP' > > 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), > > ) > > | ^ > > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetyp
Gitlab-ci? Re: Another c++ compile failure...
Actually it might be a good idea to stick CC=g++/clang++ as an additional job in .gitlab-ci.yml ? I mean, it already does gcc and clang. On Wednesday 22 May 2024 at 23:05:47 BST, Hin-Tak Leung wrote: Should be obvious - needs casting from "void *" to "unsigned char *" and etc... Shouldn't be too hard to see yourself with CC=c++ when building... In file included from /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:22:/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgload.c:421:14: error: assigning to 'FT_Byte *' (aka 'unsigned char *') from incompatible type 'FT_Pointer' (aka 'void *') 421 | if ( FT_DUP( exec->glyphIns, p, n_ins ) ) | ^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: note: expanded from macro 'FT_DUP' 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) | ~~^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: note: expanded from macro 'FT_MEM_DUP' 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), ) | ^/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: note: expanded from macro 'FT_MEM_SET_ERROR' 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) | ^~~~In file included from /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:23:/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgxvar.c:2718:12: error: assigning to 'FT_MM_Var *' (aka 'FT_MM_Var_ *') from incompatible type 'FT_Pointer' (aka 'void *') 2718 | if ( FT_DUP( mmvar, ttface->blend->mmvar, ttface->blend->mmvar_len ) ) | ^~~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: note: expanded from macro 'FT_DUP' 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) | ~~^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: note: expanded from macro 'FT_MEM_DUP' 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), ) | ^/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: note: expanded from macro 'FT_MEM_SET_ERROR' 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) | ^~~~2 errors generated.make: *** [/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/rules.mk:60: /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/objs/truetype.lo] Error 1/__w/freetype2-demos-skia/freetype2-demos-skiaError: Process completed with exit code 1.
Another c++ compile failure...
Should be obvious - needs casting from "void *" to "unsigned char *" and etc... Shouldn't be too hard to see yourself with CC=c++ when building... In file included from /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:22:/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgload.c:421:14: error: assigning to 'FT_Byte *' (aka 'unsigned char *') from incompatible type 'FT_Pointer' (aka 'void *') 421 | if ( FT_DUP( exec->glyphIns, p, n_ins ) ) | ^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: note: expanded from macro 'FT_DUP' 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) | ~~^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: note: expanded from macro 'FT_MEM_DUP' 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), ) | ^/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: note: expanded from macro 'FT_MEM_SET_ERROR' 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) | ^~~~In file included from /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:23:/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgxvar.c:2718:12: error: assigning to 'FT_MM_Var *' (aka 'FT_MM_Var_ *') from incompatible type 'FT_Pointer' (aka 'void *') 2718 | if ( FT_DUP( mmvar, ttface->blend->mmvar, ttface->blend->mmvar_len ) ) | ^~~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: note: expanded from macro 'FT_DUP' 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) | ~~^~/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: note: expanded from macro 'FT_MEM_DUP' 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), ) | ^/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: note: expanded from macro 'FT_MEM_SET_ERROR' 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) | ^~~~2 errors generated.make: *** [/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/rules.mk:60: /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/objs/truetype.lo] Error 1/__w/freetype2-demos-skia/freetype2-demos-skiaError: Process completed with exit code 1.
Re: skia-enabled ft2-demos with ot-svg suport, updated to m125 and now on github.
On Friday, 10 May 2024 at 09:03:52 BST, Werner LEMBERG wrote: > > [...] > > > > But before that, we probably want to get ft2-demos having its own > > ./configure (or cmake equivalent) first. It is a bit wierd that > > detection of librsvg happens at freetype's configure (and freetype > > itself has no use of librsvg), and CC= is also set there. I am a > > little uncomfortable using c++ compiled freetype as my system library, > > although c++ is a must for skia. (and svg-native-viewer too). > This is due to historical circumstances; it was always intended to > tightly couple the demo programs with the library. > I wonder whether we should revert the old decision of moving the demo > programs into a separate repository... > > Last I heard somebody else was comtemplating getting freetype2-demos > > its own ./confgure or equivalent? > Yes, this would also be a possibility. Alas, no GSoC student was ever > interested in overhauling FreeType's build system. ttdebug is definitely one that needs freetype internals. But ftdump/ftview/ftgrid aren't using special / non-public APIs much? To not break too much existing usages, it might be interesting to have an optionally created extra "override" makefile fragments that is loaded if it exists (created by another configure), to add some variables/options? Hin-Tak
Re: skia-enabled ft2-demos with ot-svg suport, updated to m125 and now on github.
On Wednesday 8 May 2024 at 05:09:36 BST, Alexei Podtelezhnikov wrote: > On Mon, May 6, 2024 at 2:27 PM Hin-Tak Leung > wrote: > > > > I have set up a repo for the skia ot-svg patch, updated it for skia m125 > > (out two weeks ago; skia-python m124 was released last week and there is a > > pull for m125), and set up github CI to build it against current freetype > > git head. > > > > https://github.com/HinTak/freetype2-demos-skia/ > Cool. Would you like this integrated into the main repo? You can > probably judge better if skia or rsvg is a more direct approach. > At the time those hooks were implemented I hated them because they are > just an extra layer of calls into a generic FT_Renderer module. It is > just a layer after layer of redirection so it seems. So I am for > either the most direct or the most portable code. The call stack via FT_Renderer indeed looks a bit convoluted... I wonder if it can be simplified - it would be useful perhaps extending it for COLRv1 also, since that's quite a lot of extra code (about ~1000 lines in skia, and depends on the rest of skia - so probably will be no less than that drawing bitmap raw ; Justin seems to have about 300 lines of python drawing code for each of 4 implementations). The latest librsvg seems to fix the rendering issue I filed around m116, so Nabla looks okay now. svg-native-viewer still hasn't. For a while librsvg and skia seems to be at opposite ends - one has too little man power (incomplete/bugs don't get fixed), one has too much man power (unstable API, and only care about usage inside Chrome; compilation against non-chrome projects break every few months). The long-term value of intergrating skia is probably in its having an actively maintained COLRv1 functionality. I have an additional diff with adds FT_Load_Glyph_Extended(), FT_Glyph_To_Bitmap_Extended(), FT_Get_Color_Glyph_ClipBox_Extended() which do that counterparts without "_Extended()" for COLRv1. Currently it toggles and overwrites the svg allocations, but I'd like to separate them at some point, and do it in a different way, so that color fonts with only a cOLRv1 table (i.e. without svg table) works. Such fonts don't exist "in the wild", since google color fonts have both, and the webkit folks seem not to want to support COLRv1, while the google chrome folks don't want to support OT-SVG. But before that, we probably want to get ft2-demos having its own ./configure (or cmake equivalent) first. It is a bit wierd that detection of librsvg happens at freetype's configure (and freetype itself has no use of librsvg), and CC= is also set there. I am a little uncomfortable using c++ compiled freetype as my system library, although c++ is a must for skia. (and svg-native-viewer too). The new repo has 4 submodules (skia, svg-native-viewer, freetype2, freetype2-demo) and the CI is setup to try building them one after the other, so the little green tick next to the commit (after about 20 minutes of build time) indicates a specific combinations of 4 commits works. github CI seems to have a weird bug (filed already) where submodule referring to non-github git:// repo must points to its current HEAD, so that basically means whatever else I do to update, I must sync the freetype2, freetype2-demo submodule against savannah, or it would fail. (fortunate for you to have frequent c++ build test, I guess). Last I heard somebody else was comtemplating getting freetype2-demos its own ./confgure or equivalent? Hin-Tak
skia-enabled ft2-demos with ot-svg suport, updated to m125 and now on github.
I have set up a repo for the skia ot-svg patch, updated it for skia m125 (out two weeks ago; skia-python m124 was released last week and there is a pull for m125), and set up github CI to build it against current freetype git head. https://github.com/HinTak/freetype2-demos-skia/ Documentation is a bit sparse (definitely missing a "requirement" section - read the CI yaml for what is needed), and the build scripts needs to be updated to fail properly on CI (issue 1). This is a patch to build ft2demos to use skia + its built-in svg parser, or svg-native-viewer + cairo or skia, to render ot-svg, in addition to the current, which is via rsvg + cairo (which has some bugs). The Makefile part of the patch has some harmless bits which is part of another add-on for COLRv1 I am too lazy to remove. (and is part of what I have myself https://github.com/FontVal-extras/binary-archive/ , Fontval-enhanced freetype + ot-svg & COLRv1 -enhanced ft2demos). I'll go add all the above to the README.md now :-).
small c++ breakage in current freetype git HEAD
Hi,
I have upgraded to fc40 last week, and there has been some breakage of
skia-python against current skia lately, so I thought I'd update and rebuild
the skia-enabled ft2-demos, now ported over to github CI against freetype git
head. (next e-mail). Since skia is c++, requires setting CC=c++. Found a small
breakage in current freetype git head after 2.13.2 . Diff attached - should be
obvious.
The actual error is that "enum" is a proper type in c++, and not equivalent to
"int" (as in c), so must be casted as such.
Hin-Takdiff --git a/include/freetype/internal/psaux.h b/include/freetype/internal/psaux.h
index 41f481d5a..1827219f7 100644
--- a/include/freetype/internal/psaux.h
+++ b/include/freetype/internal/psaux.h
@@ -359,7 +359,7 @@ FT_BEGIN_HEADER
#define T1_FIELD_CALLBACK( _ident, _name, _dict ) \
T1_NEW_CALLBACK_FIELD( _ident, _name, _dict )
-#define T1_FIELD_ZERO { 0, NULL, 0, 0, NULL, 0, 0, 0, 0, 0 }
+#define T1_FIELD_ZERO { 0, NULL, (T1_FieldLocation)0, (T1_FieldType)0, NULL, 0, 0, 0, 0, 0 }
/*/
Re: Accounting for SHELL in ./configure
bind mount (and anything invoking mount) requires root privilege, except for fusemount and some removable medium use cases - even that is often disabled based on site policy. Using proot-me seems to be no better than the original poster's - depending on a peculiar way of doing things maintained by a small set of individuals... The sort of thing that the initial poster tries to do, is to use a combination of docker / CI on github and other free-hosting dev platform with docker CI runners, or something like that. https://github.com/actions/runner-images I personally use docker against the ubuntu runner to grab a fefora linux docker image, and build fedora stuff there inside a fedora container running on a ubuntu host: https://github.com/HinTak/Qt6WE-OT-SVG/blob/10937a258aa3bd90533f4b9d6f67b0c61ca435e4/.github/workflows/ci.yml#L14 And here is arch linux's: https://github.com/archlinux/archlinux-docker And please stop posting links on the academic papers and promoting your papers. Not interested... On Friday, 3 May 2024 at 18:38:53 BST, Matsumura, George wrote: Greetings, I hope this is relevant and not besides the point, but I was thinking that you may be able to use proot to bind mount your shell to /bin/sh without root privileges: https://proot-me.github.io/ Hopefully this would also be useful in other situations where the SHELL environment variable is not used. Regards, George On 5/3/24 06:37, Mohammad Akhlaghi wrote: >> But you still doesn't show us an *exact* recipe or log files that >> demonstrates the problem you encounter. > > Below you can see the error: (the Readline library that '/bin/sh' needed > was more recent than our custom Readline installation; so '/bin/sh' > could not find the function it needed within our closed environment) > > /bin/sh: symbol lookup error: /bin/sh: undefined symbol: > rl_trim_arg_from_keyseq > > In our general build system for GNU-based builds (including FreeType), > we have an 'export SHELL=/path/to/custom/bash' just before calling the > './configure' script; and they would all take the 'SHELL' environment > into account during the build; so the error above didn't happen for > them. But in FreeType, we noticed that the only way we could ask it to > use our custom shell was through the 'GNUMAKE' variable. > > It would be great if the configure script can let the user specify the > shell to be used for the build in the standard way (through the 'SHELL' > environment variable). > >> Reproducibility is not equal to determinism. > > All terms and goals are precisely defined in the paper (here is the > arXiv link of the paper with no non-free Javascript): > https://arxiv.org/abs/2006.03018 > >> I dare say your problem does not happen to thousands of Arch Linux >> users who try to compile freetype. > > This problem would happen to anyone who used older versions of > https://maneage.org/. It is independent of the operating system (we build > FreeType at a time that the Maneage environment is fully closed-off from > the host). > >> you are aware that GNU Bash itself behaves differently, depending >> on what you call the binary, right? > > Thanks for the reminder on this ;-). But that is not the problem because > as mentioned before '/bin/sh' fails to link/execute at all (see error > message that is quoted above). > >> You are basically trying to do what another project "Linux from >> Scratch", tried to do 10+ years ago > > We did indeed get a lot of help from the wonderful documentation of > Linux From Scratch for the very low-level tools (we also build GCC and > GNU Binutils for example). But I would say it that Maneage is more > similar to Gentoo or GNU Guix, since it executes the scripts to build > the custom software from source automatically: no manual intervention is > necessary. Its core difference with Gentoo or GNU Guix is that it > doesn't build the Kernel and does not need root permission. This is > fully described in the paper: > https://arxiv.org/abs/2006.03018 > >> randomly changing LD_LIBRARY_PATH and other environment variables > > Nothing is random in the changes we make! > >> ... a lot of requests to the community of the form of: "I want to >> build your software my funny way, why doesn't it work?" > > My original comment was not saying this! I found the fix with a > non-standard way and there is no more problem on the Maneage side. The > reason I contacted you was that the standard solution (to set the > 'SHELL' environment variable) worked on +100 other software, it was only > FreeType and two or three other packages that need some non-standard fix. > >> The typical Linux system has thousands of packages... (last I >> count, 9000+ on fedora). Have fun going through the rest.. > > Maneage is not meant to be a full operating system! Only a closed > environment for batch (non-interactive and non-GUI) scientific > operations. Here are the current list of software that we build: > >
Re: Accounting for SHELL in ./configure
I dare say your problem does not happen to thousands of Arch Linux users who try to compile freetype. One thing on the security aspect of sh and GNU Bash - you are aware that GNU Bash itself behaves differently, depending on what you call the binary, right? If you build GNU Bash yourself, then rename the binary from "bash" to "mybash" or some random thing, "mysh" or "myhackshell", it works differently? It is by design - it detects what it is called as, and behaves differently: dropping GNU extension behavior and behaves more like pure non-GNU sh if you rename the binary, to emulate the older/stricter/more-limited shell. You are basically trying to do what another project "Linux from Scratch", tried to do 10+ years ago - randomly changing LD_LIBRARY_PATH and other environment variables that the compiler and other part of the build machinery needs, in the hope of "reproducing builds". Mostly it is a lot of requests to the community of the form of: "I want to build your software my funny way, why doesn't it work?" The typical Linux system has thousands of packages... (last I count, 9000+ on fedora). Have fun going through the rest... On Friday, 3 May 2024 at 00:11:41 BST, Mohammad Akhlaghi wrote: Thanks Hin-Tak, I will be updating the version of FreeType shortly, this was for an older project. The main purpose of going through all this trouble is long-term reproducibility of our scientific publications/results. Unfortunately that is something most operating system package managers ignore. I have published a paper on it in IEEE's Computing in Science and Engineering journal: https://doi.org/10.1109/MCSE.2021.3072860 This problem didn't happen for +100 other packages; and we are trying our best to follow POSIX/Unix standards and it has been successful so far ;-). Cheers, Mohammad On 5/3/24 12:33 AM, Hin-Tak Leung wrote: > Hmm, why are you trying to compile an older version of freetype (2.11.x), >when arch linux ships 2.13.x ? > Anyway, here is how the Arch Linux people build freetype - they use meson > instead of autoconf (PKGBUILD itself is largely a shell script with, divided > into shell script routines): > https://gitlab.archlinux.org/archlinux/packaging/packages/freetype2/-/blob/main/PKGBUILD?ref_type=heads > > PKGBUILD itself is a somewhat old package building system from BSD. > If you play with LD_LIBRARY_PATH, you are on your own... you are digging a > hole for yourself playing with that, and the hole is just deeper and deeper. > Mostly I would follow my Linux's system packaging system on how libraries are > built (so that my built result different only by my intended changes from > what's shipped by the linux distro). In your case, i would probably try to > adapt the above PKGBUILD script if i were you. > That said, i think your problem is self-inflicted - you do one thing you > shouldn't, found that it broke, and instead of just stop and revert, you do a > few more things you shouldn't and break a few more things, then do a few more > bad things, then you try to ask, why it doesn't work... > /bin/sh is hardcoded on many scripts and doesn't allow overrides, as it is a > security issue . You just should not go down the path of building bash > yourself. (And freetype's autoconf build system should have just worked > flawlessly). > > On Thursday, 2 May 2024 at 15:16:39 BST, Mohammad Akhlaghi > wrote: > > Dear Alexei, Werner and Hin-Tak, > > Thank you for the comments; I appreciate the prompt replies :-). > >> There is this peculiar autogen.sh to be run initially... Still fails? How? > > I had indeed read the README, but it had only instructed using > 'autogen.sh' when "... building a git snapshot or checkout, *not* if you > grabbed the sources of an official release." > > Since I had got the tarball as an official release (not from a Git > snapshot), I followed the instructions and ignored this step. > >> Please describe your setup carefully before jumping to quick solutions. > > The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' > is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the > Git repository and noticing that my particular problem occurred there > also, I linked the Git repository instead of the details of the tarball > I downloaded. But you are right, I should have given more details on the > circumstances; sorry about that. > >> ... nor have you shown any output of the failure. And what do you >> mean with a 'faulty shell', mentioned in a previous e-mail? > > The libraries in '/usr/lib' have conflicts with some of my other > software, so I have replaced that with my custom environment in > 'LD_LIBRARY_PATH'. However, '/bin/sh'
Re: Accounting for SHELL in ./configure
Hmm, why are you trying to compile an older version of freetype (2.11.x), when arch linux ships 2.13.x ? Anyway, here is how the Arch Linux people build freetype - they use meson instead of autoconf (PKGBUILD itself is largely a shell script with, divided into shell script routines): https://gitlab.archlinux.org/archlinux/packaging/packages/freetype2/-/blob/main/PKGBUILD?ref_type=heads PKGBUILD itself is a somewhat old package building system from BSD. If you play with LD_LIBRARY_PATH, you are on your own... you are digging a hole for yourself playing with that, and the hole is just deeper and deeper. Mostly I would follow my Linux's system packaging system on how libraries are built (so that my built result different only by my intended changes from what's shipped by the linux distro). In your case, i would probably try to adapt the above PKGBUILD script if i were you. That said, i think your problem is self-inflicted - you do one thing you shouldn't, found that it broke, and instead of just stop and revert, you do a few more things you shouldn't and break a few more things, then do a few more bad things, then you try to ask, why it doesn't work... /bin/sh is hardcoded on many scripts and doesn't allow overrides, as it is a security issue . You just should not go down the path of building bash yourself. (And freetype's autoconf build system should have just worked flawlessly). On Thursday, 2 May 2024 at 15:16:39 BST, Mohammad Akhlaghi wrote: Dear Alexei, Werner and Hin-Tak, Thank you for the comments; I appreciate the prompt replies :-). > There is this peculiar autogen.sh to be run initially... Still fails? How? I had indeed read the README, but it had only instructed using 'autogen.sh' when "... building a git snapshot or checkout, *not* if you grabbed the sources of an official release." Since I had got the tarball as an official release (not from a Git snapshot), I followed the instructions and ignored this step. > Please describe your setup carefully before jumping to quick solutions. The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the Git repository and noticing that my particular problem occurred there also, I linked the Git repository instead of the details of the tarball I downloaded. But you are right, I should have given more details on the circumstances; sorry about that. > ... nor have you shown any output of the failure. And what do you > mean with a 'faulty shell', mentioned in a previous e-mail? The libraries in '/usr/lib' have conflicts with some of my other software, so I have replaced that with my custom environment in 'LD_LIBRARY_PATH'. However, '/bin/sh' needs to link with the readline library in '/usr/lib' to run. As a result, any time '/bin/sh' is run, it will fail with a linking error. Because of this, I need to set the 'SHELL' environment variable so the programs do not build with '/bin/sh', but use my custom shell (that I have also built from source in my custom directory: I do not have root permissions on this computer). To avoid hard-coded statements like '#!/bin/sh', before './configure'-ing the source codes, I first run a 'sed' and replace it with my custom shell. This process has worked on +100 of software packages that I am building from source for my project (which uses https://maneage.org). Only a handful of packages needed some special tweaking/hacks like this one with GNUMAKE in FreeType. I am very sorry again for not being too clear in my first comment and thanks again for the prompt replies :-). Cheers, Mohammad
Re: which language you would use for X11-less macOS graphic framework?
You mean former (instead of latter), ftinspect already depends on Qt? I think you may be looking something in the "AppKit" namespace, whichever language binding you use... for the widgets, windows and buttons. On Thursday, 2 May 2024 at 16:17:02 BST, Werner LEMBERG wrote: > Again the goal is to remove dependencies like XQuartz and make it > work without it. Adding Qt or Py dependencies is not a solution. Or > this a different project. For the latter we already have `ftinspect`. Werner
Re: which language you would use for X11-less macOS graphic framework?
Quartz seems to have CGBitmapContextCreate/CGBitmapContextCreateImage ... just reading random bits of Just's python code. On Thursday, 2 May 2024 at 15:57:47 BST, Alexei Podtelezhnikov wrote: Xlib uses XPutImage. Windows uses SetDIBitsToDevice. What does macOS use?
Re: which language you would use for X11-less macOS graphic framework?
Swift is a language and a runtime; python is also a language and a runtime... objective c is a compiled language, extended c. They all provide binding to the platform's GUI toolkit. (cocoa/quartz). Swift on Linux doesn't bind to cocoa (nor x11, I think - not familiar with it). If you are going to get rid of x11, it will be mac os -specific in some degree already. One of Just's programs I have on my hard disk has `import AppKit` in it (that's cocoa), and another part has `import Quartz`. It is doing those for basic windows programming for mac os. On Thursday, 2 May 2024 at 15:37:33 BST, Alexei Podtelezhnikov wrote: > Am I missing some points? Me too. We are talking about an API which opens a window and shows an uncompressed pixel buffer in whatever language.Then it passes on keystrokes, receives an updated pixel buffer, and updates the window with it. We are talking about really basic window programming for macOS. The pixel buffer is already prepared in a system-independent fashion.
Re: Accounting for SHELL in ./configure
Besides what Werner said - name your system. Most of the world has converged on GNU bash, but Ubuntu/Debian uses dash, some older Solaris used ksh. Some really old unix system (tru64 came to mind) has genuine BSD sh. You wrote about lacking the privilege to be root, so I guess you are not using busybox. And I think FreeType can be built on the bare compiler command line without any build system, something like cc -o libfreetype.a -I./include -I... -I... */*/*.c If you set the includes and the file list (some files are not used in some platforms) right. On Thursday, 2 May 2024 at 03:49:03 BST, Werner LEMBERG wrote: Exactly. Mohammad, you have neither named your shell...
Re: which language you would use for X11-less macOS graphic framework?
I think Swift runs on Linux also these days, but perhaps without any GUI bindings. I considered installing it at some point but it is quite large (even without GUI) binding. Size we are talking about similar to Rust and Java. Open GL on Mac OS X is on the way out and quite buggy/behind mesa on Linux. You'll find accelerated graphics works on Linux but not on Mac OS X. (There are two existing bugs on skia-python specific to Mac OS X). Metal is what Apple offers instead of Open GL. There is a feature request (I filed it to remind myself...) to switch on Metal support on Mac OS X for skia-python since Open GL is lacking. Before you dive into Swift, considering watching some of Just van Rossum 's videos on YouTube for inspirations. Just is a font designer who also happens to be brother of Guido (inventor of Python). Just uses Mac OS as most graphics designer people do, and you would be amazed what you can do with Python GUI-wise on Mac OS, if your brother happens to be the most knowledgeable person about Python in the world :-) ... and check out Just's various software on github too after you check out the videos. I think Just uses pyobjc (python binding to objective c), which is bunded on mac os x's shipped Python. But, have a look at what Just uses lately; he may have some swift stuff too. Anyway, he is Mac OS-based, and his software works are open-source and mostly about fonts, so you just find plenty to take inspiration on. (I don't think he subscribes to freetype-devel, but I could be wrong...) On Thursday, 2 May 2024 at 09:59:52 BST, Ahmet Göksu wrote: Thank you for your guidance. I agree with your assessment and prefer to use Swift. It seems well-suited for future-proofing our project. Best,Goksugoksu.inOn May 2, 2024 at 11:17 +0300, suzuki toshiya , wrote: Dear Ahmet, The development of native GUI application for macOS have 3 choices: 1) Use C and Carbon framework (now obsoleted) 2) Objective-C and Cocoa framework 3) Swift I think 2) or 3) are (still) reasonable options, but 1) is not anymore. I'm unfamiliar with a market trend for Apple products, but sometimes I hear a few people (working for iOS softwares) promoting Swift as Swift is in, and Objective-C is out. Also, there would be alternative approach, like Qt, to keep from playing with Apple-specific technologies. Do you have any preference? Regards, mpsuzuki On 2024/05/02 14:30, Ahmet Göksu wrote: Hi Suzuki, Thank you, I am so excited to work with you! The new goal is Native Graphics Backend for FreeType Demos on macOS. I have updated on the GSoC website but the proposal file is unable to change. Here you can find my proposal in the attachments. Best, Goksu goksu.in On May 2, 2024 at 03:56 +0300, suzuki toshiya , wrote: Dear Ahmet, Congratulation! I'm glad to find another macOS contributor in FreeType. Please could you provide the updated estimation of the schedule, with new goal (native graphics backend for macOS, without X11)? The filed schedule dated on April 2nd was written for older goal (an improvement of ftbench and related). Regards, mpsuzuki On 2024/05/02 4:31, Ahmet Göksu wrote: Hello! Its Ahmet Goksu, last years GSoC contributor on ftbench. This year, I will be contributing development graphics backend natively on macOS without X11. Its so exciting to be here again! here are my infos to connect: https://www.linkedin.com/in/ahmetgoksu/ https://github.com/goeksu https://resume.goksu.in Best, Goksu goksu.in
Re: Question regarding gSoc 2024
(Not official) some of the freetype gsoc ideas are fairly long-term, and if it isn't done yet, then it is available. Specifically, I am not aware of any build system changes in the past 12 months. You are welcomed to come up with your project ideas, not necessarily need to be on any official lists. What's wrong with the mailing list archive which isn't "where contributors can discuss project ideas and collaborate effectively"? It is threaded, searchable, and it goes back for decades. FreeType 2 itself is about 2 decades old, with another decade before that, for FreeType 1... Discord and Slack are at most about a decade old, I think. FreeType 2 is also older than github/gitlab and older than git (the tool) itself by quite a lot, so you probably will find that freetype development does not quite follow the pull/merge requests model popularised by github/gitlab either... You can confirm definitively that a gsoc 2023 idea wasn't taken up by browsing or searching through the mailing list archive. On Thursday, 22 February 2024 at 05:11:38 GMT, Nitish Jha wrote: Hello everyone, I'm Nitish, a computer science student from India. I'm eager to contribute to FreeType for Google Summer of Code 2024, and I have a few questions. As I was exploring the idea list, I noticed that the build system project was listed as an idea for GSoC 23. I'm interested in this project, but I'm uncertain if the ideas listed on https://freetype.org/gsoc.html are intended for GSoC 24. At the top of the page, it states, "The FreeType project participates in Google Summer of Code 2023. Here is our list of possible projects." If these ideas are not for GSoC 24, could you please direct me to where I can find the ideas for GSoC 24? Additionally, I'm curious if there are any communication channels like Discord or Slack available for FreeType, where contributors can discuss project ideas and collaborate effectively. Thank you for your assistance.
Re: Creating a FreeType GitLab merge request
Yes, that sounds quite reasonable. Yes, harfbuzz is big and not everybody needs/wants all of it. To guard against bitrot, it might be useful to add (also) either compile-time or runtime switch to hb-based gpos-kerning looking up along the same code path, just to make sure that this new code doesn't bitrot? If that's done, there is a problem of which to use by default... but then we already have conditionals on harfbuzz being available, etc, so it is probably easy enough to just piggyback on that conditional. On Monday, 22 January 2024 at 20:35:17 GMT, David Saltzman wrote: this seems to duplicate functionality in harfbuzz, and also a mere subset, for that matter? Yes, that's a good question. For the product I'm working on, we wanted to add kerning support, and we already used FreeType but not HarfBuzz, and our font had GPOS kerning but not a kern table. We first tried just using FreeType's kerning API, before learning that wouldn't work because of kern tables vs GPOS. So then we tried integrating HarfBuzz, since that seemed to be the standard solution. However, after integrating that, even with HB_TINY and some custom modifications to trim it, that was too large and slow for this device; this is on an embedded device with limited flash/ram/processing speed. We have no plans to add languages that require more advanced shaping that would require HarfBuzz anyway, so it'd inevitably add a lot of unnecessary overhead. Another option was to use a script to modify the font to convert the GPOS table to a kern table, then use unmodified FreeType's kerning function; that option worked as well, though the font files ended up larger. So for a product like this, it's valuable to have GPOS kerning support in FreeType. it is also not unheard of to maintain a semi-permanent set of patches for freetype deemed unsuitable for upstreaming We do have our own copy of FreeType anyway, so we could just maintain the patch there and drop this merge request for open sourcing the GPOS kerning implementation if it's decided against taking it. It wouldn't impact us either way, but a co-worker asked to upstream this one for anyone else who may benefit from it. On the other hand, the dysfunctional kerning API, which exists, is misleading Yes, if FreeType's kerning API had just worked for our GPOS font, that would've saved us from going down this rabbit hole of kern tables and GPOS tables, and we could've remained blissfully ignorant with everything just working easily. So it would be nice to save others from that :). Another anecdote is that we also then realized that a previous product which had added kerning support through the FreeType API with its old font ended up losing kerning after the font was swapped out for one with kerning in the GPOS table, and we had shipped that update without noticing the loss; so FreeType supporting GPOS kerning as well could help prevent issues like that. The line could be drawn exactly there at the existing API. the scope of the change should be clearly defined. Drawing the line at the existing API, so leaving the scope at kerning-only and not planning to add support for other GPOS features like x-placement etc, sounds good to me. David On Mon, Jan 22, 2024 at 12:01 PM Alexei Podtelezhnikov wrote: On Jan 22, 2024, at 12:45, Hin-Tak Leung wrote: FWIW, this seems to duplicate functionality in harfbuzz, and also a mere subset, for that matter? On the other hand, the dysfunctional kerning API, which exists, is misleading. Partial GPOS support to fulfill the API promise is not a bad idea. The line could be drawn exactly there at the existing API. I agree that the scope of the change should be clearly defined.
Re: Creating a FreeType GitLab merge request
FWIW, this seems to duplicate functionality in harfbuzz, and also a mere subset, for that matter? It is rather a dead-end development direction? I think the question is, at what point do you stop? AFAIK, this kind of functionality was removed quite intentionally from freetype and moved to harfbuzz about 2 decades ago. Granted, harfbuzz is a bit too big these days - but what you are proposing sounds a lot like creating a harfbuzz-lite, a lighter weight version of harfbuzz, to be honest. For your intended usage, maybe that's what you should do - submit a series of trims, rip-outs, removals and opt-outs to remove functionality from harfbuzz to slim it down to GPOS-based kerning only... that's perhaps a more worthwhile work. FWIW, it is also not unheard of to maintain a semi-permanent set of patches for freetype deemed unsuitable for upstreaming. Yes, I am questioning putting this in freetype at all, since it was removed two decades ago and became the beginning of harfbuzz, as far as I understand. It is going backwards by two decades... On Monday, 22 January 2024 at 17:08:40 GMT, David Saltzman wrote: Thanks Alexei. I found the issue on the wiki; apparently new accounts have forking disabled by default, and new users need to file user verification tickets to get verified before being able to fork. I did that, and now forking succeeds. I filed a merge request here: https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/315. Is there a way I should add reviewers or open any needed discussion or anything else for the merge request? David On Fri, Jan 19, 2024 at 7:25 PM Alexei Podtelezhnikov wrote: Understandably, you cannot edit files in place. You need an account on gitlab.freedesktop.org and [fork] FreeType, which has been done 114 times already. Alternatively, send your patch here with a good description. Alexei On Fri, Jan 19, 2024 at 9:03 PM David Saltzman wrote: > > Hi, > > I'd like to submit a feature to FreeType. https://freetype.org/developer.html > recommends doing so via GitLab merge requests. But when I tried pushing to a > branch on the command line, git said "ERROR: You are not allowed to push code > to this project." Then I tried clicking edit->web IDE, and that said I can't > edit files in that project and I need to create a new fork. But creating a > fork from that link fails, and the fork button is greyed out on the main page. > > So do I need to join or be added to some access list, or are there other > tricks for permissions or tools to use to submit GitLab merge requests? > > Thanks, > David -- Alexei A. Podtelezhnikov, PhD
Alternative Re: Creating a FreeType GitLab merge request
Yes, I think I had an fd gitlab account ages ago but after not using it for a while it got disabled and I am having problem re-enabling it again. Anyway, I have never used the fork/pull/merge facility on gitlab with freetype ever, and it has always been the old-fashion way - how git was originally used with the Linux kernel: You just do your own work in your own local repo, and after playing with your own local branches, merges, tidying up, etc, do: git format-patch origin/main.. This exports everything between upstream (origin/main) and your current work (.. , short hand for "..HEAD", difference to the current state of your current branch) as a series of plain text patches. Send those as e-mail attachments to the right people, that's all. Or, if they are simple enough, just inline them in a email body. The old-fashioned usage of git includes using "git send-email" with those patches too, which inline them as a series of e-mails... On Saturday, 20 January 2024 at 16:36:45 GMT, Alan Coopersmith wrote: On 1/19/24 19:25, Alexei Podtelezhnikov wrote: > Understandably, you cannot edit files in place. You need an account on > gitlab.freedesktop.org and [fork] FreeType, which has been done 114 > times already. And because of restrictions implemented last year on the gitlab server to cut down on spam & abuse, you'll also need to request the ability to make forks with your new account: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: The current state of rendering and overlap
I think I agree with this - the spec should not bend on limitations/quirks/bugs in freetype. It isn't the role of the spec to recommend fonts to be built in with special "hints", just because one implementation, in its current state, can't render satisfactorily without those "hints". And, we must stress, "in its current state". Who knows, somebody might decide to ripe it all out and rewrite it differently, etc. :-). On Tuesday, 19 December 2023 at 23:55:42 GMT, Skef Iterum wrote: The better angels of my nature tell me to just leave this as it is, as this is archived and may be referenced in the future ... What you're suggesting, if I understand correctly, is that the existing flags available in the glyf implementation, and a new flag made available in the CFF2 implementation, be maintained not on the basis of whether a glyph has overlap, but by the designer based on whether the FreeType renderer in particular does a good job at rendering the glyph without the flag. This isn't unimaginable, but it comes close. What I would say is: If this is how those flags should be used, that convention should presumably be included in the portions of the OpenType/Open Font Format specification that document such flags. And this is just not how contemporary specifications work, and any such suggestion would almost certainly be rejected. It's the job of the downstream stacks to either deal with things as they come or filter up ideas that can be generalized -- and bought into -- by all the various parties, including the various other implementations. It is not the job of the specification to bend to the unilateral decisions of given implementations. Anyway, given that there will be CFF2 fonts that have no such flag, any of which could have glyphs with overlap, what should be done about those? Should I add FT_OUTLINE_OVERLAP to outlines extracted from such fonts or not? Skef On 12/19/23 11:26, Alexei Podtelezhnikov wrote: Practically speaking I don't think this could wind up being a "this glyph has overlap" flag, as in CFF2 overlap is valid anywhere. If something were added it would be more like a "this glyph doesn't have overlap, you can optimize the rendering" flag. The 4-fold speed difference is not an optimization it is a liability which should be taken explicitly. Some overlaps at single points are not that noticeable. Only long runs along the axes are bad. So I disagree with default oversampling even for variation fonts.
Re: The current state of rendering and overlap
This is the same as the winding rule concept (overlap once = wounded twice) ... I seem to remember one of them is even-odd and the other is non-zero, and quite fundamental difference between truetype and cff. On Tuesday, 19 December 2023 at 13:54:21 GMT, Alexei Podtelezhnikov wrote: It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a CFF2 font. Whether that makes sense is one thing I'd like advice about. There's currently no such code. I would suggest that CFF2 invent a special charstring to mark overlaps with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement it in FreeType. https://www.w3.org/TR/WOFF2/#p1 WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can spare a reserved operator or a two-byte operator.
Re: Which download to build for Windows 11 Pro?
It is still not exactly clear what you are trying to do, and how/why you are going about it. Feeetype-py for windows AFAIK bundles the freetype dll, although there is a not yet merged pull which tries to build the bundled freetype dll with more features:https://github.com/rougier/freetype-py/pull/149 I assume this is you too... - why are you trying to rename files? https://github.com/rougier/freetype-py/issues/182 If you ramdomly rearrange and rename files, you get random brokenness... On Friday, 15 December 2023 at 15:21:29 GMT, Alexei Podtelezhnikov wrote: Which file should I download for building freetype dll on Windows 11 Pro for use with Python? | | | | ubawurinna/freetype-windows-binaries: Windows binaries of FreeTypegithub.com | | But if you insist on building it yourself, you should ask more specific question and describe your compilation tools.
Re: Freetype for Python. AttributeError: module 'freetype' has no attribute 'Face'
Both comments from Alex are wrong...
freetype-py has its own versioning, it is confusing, but 2.4.0 is current:
https://github.com/rougier/freetype-py/releases
And has its init hook too:
https://github.com/rougier/freetype-py/blob/master/freetype/__init__.py
I think that the python load path of the initial poster is wrong. Ie. You are
not loading freetype-py, but something else which happens to have a
"freetype.py" file, for example. It could be his own code - if he has a file
called freetype.py himself, that would be loaded instead of the (system-wide)
freetype-py package. Quite a common mistake, to have all user code interacting
with freetype-py in a new file called "freetype.py" (in the current directory),
or a user file "skia.py" to interact with skia-python, etc.
On Friday, 15 December 2023 at 02:50:03 GMT, Alexei Podtelezhnikov
wrote:
I have bindings for freetype 2.4.0 for Python. I dont understand why that:
Do you realize that this version is 13 years old? I recently saw a current
FreeType version in the anaconda environment. Just saying…
AttributeError: module 'freetype' has no attribute 'Face'
is coming from:
import freetypeface = freetype.Face("Vera.ttf")face.set_char_size( 48*64
)face.load_char('S')bitmap = face.glyph.bitmapprint(bitmap.buffer)
FreeType requires initialization (internal module loading). See if you can find
some _init_ method that you might need to call first.
Skia-python 120 b5 is out (or soon out, in a few hours)
The binary wheels are being built and deployed at the moment. https://github.com/kyamagu/skia-python/releases/tag/v120.0b5 The combination of OT-SVG on-by-default for freetype and directwrite, and the option to use freetype to load fonts on non-linux, should imply that OT-SVG fonts should "just work" on Linux, Windows and Mac OS, somehow. I'll like to see windows users try to load OT-SVG fonts normally - I.e. via DirectWrite, to see whether that works or not, or figure out why it doesn't, before switching to the non-host font loader path. (AFAIC it should work with directwrite, but doesn't, according to github CI - I don't use windows so am just relying on writing pytests and throwing the tests at CI...) It is still beta, as the pytest pass rate was quite low for the m11x's and gradually climbing, currently at 2072 / 2193 for m120. C.f pytest pass rate for the last release m87 was 2171 / 2206. I.e. some 5% of old functionality (even if those are **extremely** rarely used) is still missing. New to this release: New in m120: - Rudimentary support (TextBlob::MakeFromShapedText) of text-shaping via upstream's libSkShaper module. Intially this was added to support emoji's with skin-tone modifiers (#195), but has the fortunate side-effect that now LTR languages (Arabic, Hebrew, Tibetan ...) work as desired in skia-python's drawing. Note libSkShaper is buggy on windows. ( https://issues.skia.org/issues/310510988 ) - Option to use freetype as fontmgr on non-linux (#213) - using skia.FontMgr.New_Custom_Empty() (upstream's SkFontMgr_New_Custom_Empty). This allows Windows/Mac users to use some font formats not supported by DirectWrite/CoreText (see #195); and also work around bug in CoreText (#138, https://issues.skia.org/310510989 ). - OT-SVG font support is on by default now (#212, also see #195). - Vulkan is enabled for Linux/Windows. Most of the APIs were in m87 (stubs?) but were made optional in m98+, and dependent on GPU backend compiled in. For Mac OS X users, upstream removed MoltenVK support in m83, and recommend using Metal backend (TODO).
Re: [IDEA] Facilities to extract TT fonts from TTC font collections
On Monday, 23 October 2023 at 17:36:09 BST, Werner LEMBERG wrote: > > I recently had to extract a TrueType font from a TTC font collection > > as part of fixing bugs in the podofo library[1]. > In general, FreeType is not the right tool for such operations. > FreeType is a *rendering* library that provides a thin API for > extracting SFNT tables, mainly the ones FreeType isn't parsing by > itself. As Behdad mentioned, the `fonttools` package should help you > with your task. Besides fonttools, this isn't heavily advertised, but Font Validator's ironpython scripting interface has an example script called "ttc-splitter.py" for doing exactly that. And a "ttc-merger.py" script too, as well as a "ttx-l.py" script, which does what fonttools "ttx -l" does, ie listing font tables. They are located in Font-Validator/bin/scripting-examples/ . FontVal contains very little font-modification/writing related code as it is a font checking tool, but somehow Microsoft had included some font-writing code in there, for unknown purposes. The scripting interface uses Ironpython (an implementation of python interpreter running on microsoft Dot Net / xamarin mono) and we bundle the iron python interpreter, actually. But AFAIK I am the only person who uses that part of FontVal as part of the bulk half-yearly-ish testing on all fedora-shipped fonts.
Re: Implementing Skia OT-SVG hook bridge in ftinspect?
I have now rebuilt the ft2-demo rpm ( github.com/FontVal-extras/binary-archive/) against m118. There is no change to the ft2-demo patch between m117 and m118. There was a small difference between m116 and m117 - headers are more separate and no longer includes related ones so there were two additional lines of includes from m116 and m117. I just checked - the header moved I mentioned was between m110 and m116. One particular header had moved within skia. I realised I actually haven't uploaded the m117 version of the diff (since I am really using the COLRv1 diff which is a larger one). I shall do that now and also put a symlink to m118 too, since it is identical. On Thursday, 28 September 2023 at 13:30:42 BST, Hin-Tak Leung wrote: The answer to the first question, as a whole, is no. Skia people don't guarantee anything. Skia is always statically linked to google chrome for that reason; shared library builds are there as is but not really supported. That said, the ft2-demos skia-port code use very little of skia, and doesn't change since m103 AFAIC. The skia build result is more or less stable. I'd say you give it a try. The shared libraries get deposited at out/Shared/ (configurable and can be out of tree), and includes are in include/ and modules/ , both relative to the bottom skia/ directory. I would suggest getting rsvg-ports.[ch] (and rsvg/cairo) working with ftinspect first. The bridge interface is all the same - it is just what the actual "hooks" passed to FT_Set_Properties() is different. The mention of skia-python is just to say what's the busy part is... out of the ~2400 API of skia, skia-port only uses 10 to 20. Well, actually I have an exact answer: nm -D -C /usr/bin/ftview | grep Sk | wc -l is 35. That's inclusive of the COLRv1 code, which I have only posted the skia side changes so far. (The ft2-demos side is still too ugly, and I am not spending much time on it any time soon) On Thursday, 28 September 2023 at 09:10:38 BST, Charlie Jiang wrote: Hin-Tak, Hello. - About the Skia version issue, it would be extreme concerning if every time Skia releases a new version, the bridge code has to be changed... Is there any degree of stability guaranteed for SVG-related interfaces (header files, class/method/function names...)? - About the build system, is the directory structure of results from Skia's gn build system and prebuilt Skia binaries stable? If so, we can use something like `FindSkia.cmake` to locate the libraries and include directories required to compile against Skia from a simple `SKIA_DIR` CMake or Meson variable. - About skia-python, I'm not planning to introduce skia-python or freetype-py... Since ftinspect is a pure C++ project, I wonder if any Python part is required to incorporate Skia into ftinspect. Glad to know that Skia won't cause circular dependency. Charlie Jiang
Re: Implementing Skia OT-SVG hook bridge in ftinspect?
The answer to the first question, as a whole, is no. Skia people don't guarantee anything. Skia is always statically linked to google chrome for that reason; shared library builds are there as is but not really supported. That said, the ft2-demos skia-port code use very little of skia, and doesn't change since m103 AFAIC. The skia build result is more or less stable. I'd say you give it a try. The shared libraries get deposited at out/Shared/ (configurable and can be out of tree), and includes are in include/ and modules/ , both relative to the bottom skia/ directory. I would suggest getting rsvg-ports.[ch] (and rsvg/cairo) working with ftinspect first. The bridge interface is all the same - it is just what the actual "hooks" passed to FT_Set_Properties() is different. The mention of skia-python is just to say what's the busy part is... out of the ~2400 API of skia, skia-port only uses 10 to 20. Well, actually I have an exact answer: nm -D -C /usr/bin/ftview | grep Sk | wc -l is 35. That's inclusive of the COLRv1 code, which I have only posted the skia side changes so far. (The ft2-demos side is still too ugly, and I am not spending much time on it any time soon) On Thursday, 28 September 2023 at 09:10:38 BST, Charlie Jiang wrote: Hin-Tak, Hello. - About the Skia version issue, it would be extreme concerning if every time Skia releases a new version, the bridge code has to be changed... Is there any degree of stability guaranteed for SVG-related interfaces (header files, class/method/function names...)? - About the build system, is the directory structure of results from Skia's gn build system and prebuilt Skia binaries stable? If so, we can use something like `FindSkia.cmake` to locate the libraries and include directories required to compile against Skia from a simple `SKIA_DIR` CMake or Meson variable. - About skia-python, I'm not planning to introduce skia-python or freetype-py... Since ftinspect is a pure C++ project, I wonder if any Python part is required to incorporate Skia into ftinspect. Glad to know that Skia won't cause circular dependency. Charlie Jiang
Re: Implementing Skia OT-SVG hook bridge in ftinspect?
A few things... - skia-port.[ch] isn't the only OT-SVG bridge - it is better than rsvg-port.[ch] (rsvg/cairo-based) in skia's svg processing is more complete. but rsvg-port.[ch] are already in. - skia has a 4-6 week release cycle. I started with m116; m117 didn't change much as far as the bridge code is concerned (I think one upstream header has moved location). Most of the questions about building skia is answered by the shell-script in https://github.com/HinTak/skia-building-fun/ - it takes one argument, the branch name (m116, m117, m118, etc, but also m87, m88 for some of the older ones I tested), and build a zip files with shared libraries and headers. You unzip into a skia/ sub-directory of ft2-demos/ to build . So the building of the skia shared-libraries and ft2-demos are completely separate. This is how I build https://github.com/FontVal-extras/binary-archive/ these days - the "source" rpm has an extra zip file with that skia binary bundle, build ft2-demos with them, then packaged those shared libraries in system locations as well as the ft2-demos binaries as rpms. - I would advise against adding meson files. Skia is moving too fast and another bolted-on build system would bit-rot very fast. Other than the shell script in https://github.com/HinTak/skia-building-fun/, I would take some tips from scripts/build_Linux.sh of skia-python, to build gn from source. That way, you build gn, requires ninja, and (look at the shell script), fetch about 5 git repo on-the-fly, and you can build skia in about 20 minutes with 300MB disk space needed. If you really want to disable network access while building, grab and snapshot those 5 repo's. The 5 is listed in one of the patches in https://github.com/HinTak/skia-building-fun/ . - yes, there is extra dependencies. But so has harfbuzz <-> freetype, etc. It is not exactly circular in this case: ft2-demos depends on skia depending on libfreetype (and libjpeg, fontconfig, etc), and also directly on libfreetype. - I haven't looked at ftinspect, but for most freetype-dependent programs, it is just #include "rsvg-ports.h" // or "skia-port.h" FT_Property_Set( handle->library, "ot-svg", "svg-hooks", _hooks ); // or one of the others before you do FT_Load_Glyph(...) . This is done in ftview and also in ftgrid (or I added it in the patch?). - the python equivalent is the similar, any freetype-py dependent python scripts, from otsvg import hooks library = get_handle() FT_Property_Set( library, b"ot-svg", b"svg-hooks", byref(hooks) ) In https://github.com/HinTak/harfbuzz-python-demos/ , "hb-view-ot-svg.py" is the rsvg-based example. "hb-view-ot-svg-skia-GL.py" is the skia openGL example. I haven't built m118 for https://github.com/FontVal-extras/binary-archive/ yet - mostly just time. AFAIK the skia-based bridge code is stable and expect not to change much across skia versions. skia-python is a bit more of a pain. skia-python covers about half of skia, and with skia changing so fast, skia-python is getting broken every month, if you try to follow skia's release cycle in skia-python :-(. If you want to quantify, the last time I counted, freetype has about ~220 (?) public routines. freetype-py exposes about half to 70% of those. Skia has about 2400 public routines; skia-python m87 expose over 1000 - it is a bit difficult to count as skia-python uses dynamic casts, so dependencies don't show up at link-time. about 200 (or 20%) were broken in m116 initially, between m87 to m116 (29 releases, or about 3 years) . I think it is down to about 100 broken at the moment in m117b3, just out. On Wednesday, 27 September 2023 at 02:55:41 BST, Charlie Jiang wrote: Hi Hin-Tak, Werner and other folks, The recent posts from Hin-Tak provided us promising insights in implementing OT-SVG hook bridges in calling programs. I wonder if the current status of Skia hook is approriate for being incorporating into ftinspect. My considerations are: - Maturity of bridge code (namely, skia-port.[ch]): Are they performing well enough for a (experimental) integration? Do they work stably across Skia versions? I'm seeing different patches for different Skia versions; - Building Skia: Skia is built using tools (e.g. gn) completely different from what we're using for building ftinspect (CMake and Meson). I plan to not directly include the commands to build Skia into the ftinspect build system, but to ask user to provide Skia library paths. However, I'm concerned that Skia depends on (possibly another build of) freetype, which may cause conflict. Maybe Hin-Tak have some tips on handling this correctly? If done, I plan to flag this feature as experimental and optional (default disabled, enable in build system). However, I may lack the resources and experise to test the code thoroughly, so I wonder if Hin-Tak could help. BTW @Hin-Tak, The Qt6 support for ftinspect has almost completely not been worked on, I just wrote the
Re: ftbench: last updates
Hi Ahmet. I'll leave Werner to say something definitive, but in my opinion, given the project will be put aside and/or merge with some incomplete area soon, for some possibly long period before you or somebody else revisit the tasks/goals, it is particularly important to document things clearly. Not just in terms of formal documentations in the various readme's, but also adding "TODO", "Known limitations" in the code. Like "notes and reminders to future self" if you need to come back to it and continue after 5 years :-). As for meson and cmake - if you do add/change something at this stage, be sure to write a bit more about what state it is in, in the commit message. It will be quite annoying for somebody else, or you yourself for that matter, to look at some large chunk of code in a year or two, and think: "what state this was in, did this work at all? Has this gotten broken recently, or never did work?". I think one example might be qt6 support for ftinspect - there are some work/code going towards it, but it would be nice to see a comment where it matters - around where one might switch from qt5 to qt6 - that it doesn't quite work yet. There are always going to be incomplete/work-in-progress areas, so the general direction would be write down things clearly so you or someone else can revisit later and continue with as much help and information as you can give now. On Sunday, 17 September 2023 at 12:35:08 BST, Ahmet Göksu wrote: Thanks Hin-Tak, I am developing on a Mac. Also, While there are less than 10 days for final evaluation, there are points that are not completed: *meson *cmake *documentation because of our focus a bit changed, didnt worked on them much. Should I complete them all? Is there a priority? Best,Goksugoksu.inOn 17 Sep 2023 02:31 +0300, Hin-Tak Leung , wrote: I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime So unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it. On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu wrote: Hello, -I have changed the * and the sentence -changed the links to relative I already changed the working way of the timing. I only start the benchmark at beginning and stop at the end. i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test. BTW, I suggest that you add another sentence, explaining *why* there are two values at all. actually, i didnt get the reason well but it may differ even with same flags. i need help in this case. as i said before, i run the benchmark in mac. it uses this if clause. return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine? Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: If a value in the 'Iterations' column is given as '*x* | *y*', values *x* and *y* give the number of iterations in the baseline and the benchmark test, respectively.
Re: ftbench: last updates
I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime So unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it. On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu wrote: Hello, -I have changed the * and the sentence -changed the links to relative I already changed the working way of the timing. I only start the benchmark at beginning and stop at the end. i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test. BTW, I suggest that you add another sentence, explaining *why* there are two values at all. actually, i didnt get the reason well but it may differ even with same flags. i need help in this case. as i said before, i run the benchmark in mac. it uses this if clause. return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine? Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: If a value in the 'Iterations' column is given as '*x* | *y*', values *x* and *y* give the number of iterations in the baseline and the benchmark test, respectively.
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
Besides those two questions - who maintains that color font compiler, and where else can you find fonts with similar problems, not made by Google. I just had a third - given that those fonts don't work at all with any of the usual SVG readers/editors, and freetype can't read them correctly until the skia-based OT-SVG bridge came, and that google chrome still does not support OT-SVG fonts after a whole decade (apparently it was added to skia m103 about a year ago, but haven't been enabled...), how/where do you test those fonts on any platforms? On Monday, 4 September 2023 at 19:00:12 BST, Hin-Tak Leung wrote: Hmm, "nanoemoji color font compiler" is maintained by? It is largely for simplicity - you can try find some colour fonts from other sources which show the same problems? On Monday, 4 September 2023 at 13:21:11 BST, Cosimo Lupo wrote: 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 rendered as standalone SVG documents, because there are OT-specific semantics. Can you please stop referring to these as the "Google OT-SVG", there is nothing particularly Googley about it. Thank you. On Mon, Aug 21, 2023 at 5:15 PM Hin-Tak Leung wrote: Just put it through: https://github.com/rougier/freetype-py/blob/master/examples/ot-svg-example-skia.py It depends on material in the next skia-python, 117b3:https://github.com/kyamagu/skia-python/pull/197 I think the current plan is for about a dozen beta releases until about skia-python m130 b16 , in the next year and half. (Skia has new release every 4 to 6 weeks...) If things go well, there might be a non-beta release by then. This is probably the easiest way of coping with some *cough* google *cough* OT-SVG fonts, given rsvg and Adobe Native can't cope. Skia-python comes with a bundled skia, so you don't have to build it yourself. The plan is to release skia-python m117 b3, whatever state it is, when upstream m118 appears (in about two weeks' time...), etc, until about m130 b16, at least. On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung wrote: Hi, it has been a while with any traffic on the create list. I have had some fun recently with downloading and building skia with ~80MB nework traffic and ~300MB disk space usage, without compromising on functionality: https://github.com/HinTak/skia-building-fun/ Thought it is probably useful for other projects like libreoffice, etc. Potentially that means Skia is package'able as a shared library for wider use. Quite surprised that Google Fonts make SVG's in their OT-SVG fonts that some of the most common SVG editors/viewers cannot read correctly: https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 https://github.com/adobe/svg-native-viewer/issues/185 https://gitlab.com/inkscape/inbox/-/issues/8857 What other SVG editors/viewers are out there? (besides Skia and Webkit, that is - those two work okay). I haven't given batik a go yet. The context is that I have a few different options of enabling OT-SVG support on any freetype-based application, with an operational but still ugly (code-wise) addition for COLRv1. https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure/
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
Hmm, "nanoemoji color font compiler" is maintained by? It is largely for simplicity - you can try find some colour fonts from other sources which show the same problems? On Monday, 4 September 2023 at 13:21:11 BST, Cosimo Lupo wrote: 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 rendered as standalone SVG documents, because there are OT-specific semantics. Can you please stop referring to these as the "Google OT-SVG", there is nothing particularly Googley about it. Thank you. On Mon, Aug 21, 2023 at 5:15 PM Hin-Tak Leung wrote: Just put it through: https://github.com/rougier/freetype-py/blob/master/examples/ot-svg-example-skia.py It depends on material in the next skia-python, 117b3:https://github.com/kyamagu/skia-python/pull/197 I think the current plan is for about a dozen beta releases until about skia-python m130 b16 , in the next year and half. (Skia has new release every 4 to 6 weeks...) If things go well, there might be a non-beta release by then. This is probably the easiest way of coping with some *cough* google *cough* OT-SVG fonts, given rsvg and Adobe Native can't cope. Skia-python comes with a bundled skia, so you don't have to build it yourself. The plan is to release skia-python m117 b3, whatever state it is, when upstream m118 appears (in about two weeks' time...), etc, until about m130 b16, at least. On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung wrote: Hi, it has been a while with any traffic on the create list. I have had some fun recently with downloading and building skia with ~80MB nework traffic and ~300MB disk space usage, without compromising on functionality: https://github.com/HinTak/skia-building-fun/ Thought it is probably useful for other projects like libreoffice, etc. Potentially that means Skia is package'able as a shared library for wider use. Quite surprised that Google Fonts make SVG's in their OT-SVG fonts that some of the most common SVG editors/viewers cannot read correctly: https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 https://github.com/adobe/svg-native-viewer/issues/185 https://gitlab.com/inkscape/inbox/-/issues/8857 What other SVG editors/viewers are out there? (besides Skia and Webkit, that is - those two work okay). I haven't given batik a go yet. The context is that I have a few different options of enabling OT-SVG support on any freetype-based application, with an operational but still ugly (code-wise) addition for COLRv1. https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure/
Re: ttfautohint's functionality from the removal of the infinality patch
On Friday, 25 August 2023 at 05:38:14 BST, Alexei Podtelezhnikov wrote: > Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting > v38 got v40 instead... and nobody even noticed. That is the whole > point of the exercise: v40 is perfectly capable and better than just > good enough. Now the code is physically gone for good. It is much > better to improve faster and lighter v40 moving forward than dwelling > on unmaintained, poorly understood, and riddled with exceptions v38. "Better" is your personal opinion. Anyway, I think some of others' "personal opinion" (different from yours) is simply based on familiarity - some people are just more familiar with MS/Apple rendering, and therefore prefer it. In the end of the day, FreeType is not MS/Apple font scaler. Fact. As long as v38 is different from v40, some part of it is closer than v40 to MS/Apple's. Also fact.
6th OT-SVG hook bridge (Re: skia as a shared library, and the (poor) support for Google's OT-SVG variant by libre software
Just put it through: https://github.com/rougier/freetype-py/blob/master/examples/ot-svg-example-skia.py It depends on material in the next skia-python, 117b3:https://github.com/kyamagu/skia-python/pull/197 I think the current plan is for about a dozen beta releases until about skia-python m130 b16 , in the next year and half. (Skia has new release every 4 to 6 weeks...) If things go well, there might be a non-beta release by then. This is probably the easiest way of coping with some *cough* google *cough* OT-SVG fonts, given rsvg and Adobe Native can't cope. Skia-python comes with a bundled skia, so you don't have to build it yourself. The plan is to release skia-python m117 b3, whatever state it is, when upstream m118 appears (in about two weeks' time...), etc, until about m130 b16, at least. On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung wrote: Hi, it has been a while with any traffic on the create list. I have had some fun recently with downloading and building skia with ~80MB nework traffic and ~300MB disk space usage, without compromising on functionality: https://github.com/HinTak/skia-building-fun/ Thought it is probably useful for other projects like libreoffice, etc. Potentially that means Skia is package'able as a shared library for wider use. Quite surprised that Google Fonts make SVG's in their OT-SVG fonts that some of the most common SVG editors/viewers cannot read correctly: https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 https://github.com/adobe/svg-native-viewer/issues/185 https://gitlab.com/inkscape/inbox/-/issues/8857 What other SVG editors/viewers are out there? (besides Skia and Webkit, that is - those two work okay). I haven't given batik a go yet. The context is that I have a few different options of enabling OT-SVG support on any freetype-based application, with an operational but still ugly (code-wise) addition for COLRv1. https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure/
Re: ttfautohint's functionality from the removal of the infinality patch
On Sunday, 20 August 2023 at 18:28:54 BST, Dave Crossland wrote: > Since almost all new fonts are vf, I'm no longer seeing ttfautohint in > common usage, but I don't think it's effected by this. That's not necessarily true - people with poorer monitors are also likely to be less technically competent, and therefore unlikely to ever actually report any issues. (I am just saying that, it is actually quite dangerous and partial for people with expensive high-def monitors to decide what is and what isn't "generally" relevant ...)
Re: ttfautohint's functionality from the removal of the infinality patch
On Friday, 18 August 2023 at 22:27:26 BST, Werner LEMBERG wrote: > > Are we getting into a situation where ttfautohint is hinting for the > > (limited) "good enough" light hinting model of recent freetype? > It's not clear what you are actually asking. ttfautohint is an > incarnation of FreeType's auto-hinter, translated into TrueType > bytecode, more or less. This is not related to interpreting bytecode. But does it contain hidden assumptions about how bytecodes are interpreted (by specific renderer, and specific version of now-simplified renderer )? > Well, the Infinality stuff was basically unmaintained; it essentially > consisted of a large bunch of exceptions for some special fonts. > Alexei and I agree that we no longer need this. There was not a > single voice objecting to its removal, by the way... I agree there is no general usage for it. For the purpose of fontval's backend, until a genuine Microsoft backend happens (if ever), I suspect that the infinality stuff behaves closer to Microsoft renderer towards Microsoft hinted fonts. So if the goal is not "good enough hinting" but "matching Microsoft behavior", it has to stay. So FWIW, I am just mentioning that I will carry a reverse diff in future version of Fontval, if another release ever happens...
ttfautohint's functionality from the removal of the infinality patch
Hi, Yesterday's opentype font meeting touched upon hinting and ttfautohint briefly. I see the infinality patch is already gone (next release, 2.13.2 I guess - bits of it was removed in 2.13.1 already). Question is, does its removal impact the functionality of ttfautohint? Are we getting into a situation where ttfautohint is hinting for the (limited) "good enough" light hinting model of recent freetype? And dropping support, and/or compatibility/ awareness of intended usages of outcome in other *cough* microsoft *cough* hinting models? FWIW, fontval will carry the reverse diff. "Good enough" hinting isn't good enough - some people just want familarity, so nothing except Microsoft releasing a (binary-only) backend is good enough :-(. Unless/until that happens, variety (even if it is "poorer", for a value of "poorer") is important.
Re: -warmup
On Friday, 18 August 2023 at 00:21:41 BST, Ahmet Göksu wrote: > about outliers, i splitted every tests into chuncks that is sized 100. Made > IQR calculations and calculated average time on valid chunks. you can find > the result in the attachment also pushed to gitlab. > also, since statistics and benchmarking are a sciences their self, i am a bit > struggling while approaching the problem as well as feels like out of the > gsoc project scope. I would like to share this with your indulgence. yet, of > course I will move in accordance with your instructions. Hmm, this is lacking basic maths skills... cutting into chucks and recombining them aren’t going to deal with outliners. Read about "median", "quantile" on Wikipedia/Google'ing. Anyway, you want to calculate the "median" time. E.g. sort 100 numbers by size, getting the average of 50th and 51th, and your error is the difference between the 91th and the 10th quantile. ( the 10th and the 91th when you sort them in order of size). If you can do that for the entire set, do it for the whole set; if not, a running median - ie. The median of every chuck of 100. Then combine the running medians. This way, the top 9 and bottom 9 values of each 100 have no contribution at all to your outcome. This is dealing with outliners.
Re: Progress update on adjustment database
On Saturday, 12 August 2023 at 17:17:47 BST, Werner LEMBERG wrote: > > It is one of those things I never remember - winding rule of > > truetype and postscript are different, one is even-odd, the other is > > non-zero. [...] > You are on the completely wrong track here. What I'm talking about is > strictly local and not (directly) related to having two different > contours. For example, to recognize stems and serifs, the contour > must be the same. In case you are not aware of how the auto-hinter > collects 'segments' and 'edges', please read > https://www.tug.org/TUGboat/tb24-3/lemberg.pdf > which still gives a good overview (inspite of its age and some changed > details here and there). Argh, sorry :-).
Re: Progress update on adjustment database
It is one of those things I never remember - winding rule of truetype and postscript are different, one is even-odd, the other is non-zero. That concerns the number of times a line joining an "interior" (inked) point going to infinity, how many times it crosses the glyph contour. Anyway, viewing from a small gap between two "inked" portion, the two contours on either side must be running in opposite direction. There is a simple case where two contours runs in the same direction: think of a single connected contour that is like two circles except it crosses itself at one point (just say, the top - ie. You draw anti-clockwise from 12, when you get to 1, move inward to draw another circle, and move outward to 12 to join original when you get to 1 a 2nd time). I think the two winding rules means in either case, the region between the inner/outer part is inked (viewing from that area locally, you see contours running in parallel), because the contour goes around you "once". Whether the inner circle is inked depends on whether you are talking postscript/cff or truetype. One is inked, the other is not. (That region is enclosed by the contour globally "twice" - hence difference in even-odd versus non-zero). So this self-intersecting contour should either be drawn as mostly an 'o' shape, or a solidly inked circle. Granted, self-intersecting contours are rare, but they are legal. Anyway, a small gap we have been discussing for which we want to preserve during hinting, locally if you are sitting at that spot, you see contours running in opposite directions around you. If you see contours running in the same direction, you are possibly in a inked part instead, like between the self-intersecting bi-circle I just told you. On Saturday, 12 August 2023 at 06:43:14 BST, Craig White wrote: I'm still missing something. Why would the direction of the contour matter if, in either case, it's the same set of points? On Fri, Aug 11, 2023 at 6:52 AM Werner LEMBERG wrote: > You said that for an i - like shape: >> Both contours have the same direction. > > What kind of problems does this rule protect against? Sorry, this was sloppily formulated. It's about the *local* direction of contours, that is, whether a horizontal contour segment goes from left to right or from right to left. For the 'i' stem and the 'i' dot, both contours must have the same direction globally, but locally, at the dividing space, the corresponding lower and upper segments must have the opposite directions. Werner
skia-python 116.0b2 is out (Re: skia as a shared library, and the (poor) support for Google's OT-SVG variant by libre software)
skia python 116.0b2 is out. You can get at it with "pip ... --pre ...". Part of the release notes: "It concentrates on OT-SVG, and fixing these two issues ... Some COLRv1-related Skia internals from upstream's on-going effort in this area are also exposed for access. This experimental functionality is available to Linux/FreeType users only." Since upstream skia m117 is out already, the next skia-python isn't 116b3, but 117b2 or 117b3. Between v87 and v116b2 is about 5000+ lines of code difference. I estimated that it will need ~30,000 to release 116 proper... so it will be another year or 10 betas or so, up to at least 130.0b2 :-(. Upstream skia m116 to m117 is about 800 commits, or about 20+ changes per day. That said, important old APIs are emulated. Most of not-working v87 parts are either rarely used or upstream decided to withdrawn, so most people won't notice the difference or miss anything by moving to 116b2 (hopefully). On Thursday, 27 July 2023 at 00:43:00 BST, Hin-Tak Leung wrote: Hi, it has been a while with any traffic on the create list. I have had some fun recently with downloading and building skia with ~80MB nework traffic and ~300MB disk space usage, without compromising on functionality: https://github.com/HinTak/skia-building-fun/ Thought it is probably useful for other projects like libreoffice, etc. Potentially that means Skia is package'able as a shared library for wider use. Quite surprised that Google Fonts make SVG's in their OT-SVG fonts that some of the most common SVG editors/viewers cannot read correctly: https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 https://github.com/adobe/svg-native-viewer/issues/185 https://gitlab.com/inkscape/inbox/-/issues/8857 What other SVG editors/viewers are out there? (besides Skia and Webkit, that is - those two work okay). I haven't given batik a go yet. The context is that I have a few different options of enabling OT-SVG support on any freetype-based application, with an operational but still ugly (code-wise) addition for COLRv1. https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure/
Re: benchmarking and plans for upstreaming the 4-hook patch, and COLRv1 extension.
The script to download and build skia with 80MB download and 300MB disk use is athttps://github.com/HinTak/skia-building-fun . Takes about 40 minutes on dual core. Most things about the 4 hooks and COLRv1 extension stays athttps://github.com/HinTak/harfbuzz-python-demos But a COLRv1-related patch will land in the building fun repo at some point, to patch skia with a few extra routines etc to make getting at COLRv1 functionality easier... On Monday, 24 July 2023 at 09:59:32 BST, Hin-Tak Leung wrote: Hi, The most exciting thing I have done this weekend, is managed to have a procedure/patch-sets to build current skia with max download/clone of about 80MB and max disk usage of about 300MB. Skia takes about 40 minutes to build on dual-CPU (or about 70 minute on single CPU). Without compromising on any functionality. Skia is facinating in both a bad and good way. The official build procedure does a 900MB clone, then fetch 1.6GB swiftshader (mac os x only), 1GB icu (available on Linux), 400MB angle2 (used only windows builds); 5.1GB of thirdparty stuff in total. Then it goes and fetch another 400 MB via emsdk and dump 1.1GB on the hard disk (only useful for building skia for web-assembly). So it eats up 900MB + 5.1GB + 1.1GB ~ 7.1GB before you even start to build any skia source code. !!! If you do shallow clone, only care about linux, and use system libraries as appropriate, you can cut the 7.1GB disk usage down to about 270MB. And the network usage from 600MB + ~2.5GB + 400MB ~ 3.5GB to about 80MB download. So I think we can already start talking about upstreaming the 4-hook diff, because it is now possible to build the whole thing entirely from source without ready-made binary bits from elsewhere, in about an hour. And going towards the COLRv1 extension. Here is what I have in mind in 4 stages: - there are two uncontroversial diffs: adds no_svg /color layer glyph toggle keys to ftgrid, and symbol hiding in rsvg-port.c . The svg hook routines are entirely used via "hook->svg_init", so they don't need to be named at all. - At the moment I use something like this in the Makefile: + $(OBJ_DIR_2)/rsvg-port.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsrvg-port.h + $(COMPILE) $T$(subst /,$(COMPILER_SEP),$@ $<) + + $(OBJ_DIR_2)/rsvg-port-alt.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsvg-port.h + $(COMPILE) -DUSE_ADOBE=1 $T$(subst /,$(COMPILER_SEP),$@ $<) FTCOMMON_OBJ := $(OBJ_DIR_2)/ftcommon.$(SO) \ $(OBJ_DIR_2)/ftpngout.$(SO) \ - $(OBJ_DIR_2)/rsvg-port.$(SO) + $(OBJ_DIR_2)/rsvg-port.$(SO) \ + $(OBJ_DIR_2)/rsvg-port-alt.$(SO) To build the same source file twice, differently, to switch between "rsvg + cairo" and "adobe + cairo". This trick depends on the symbol hiding change. We need something better and more configurable than this? The current assumption is that "svg-native-viewer/" is a sub-directory, and have a separate set of build instructions. - Once we have figured out the "rsvg + cairo" and "adobe + cairo" combination, then, the pair "adobe + (older/any) skia" and " pure skia (m103+)" can be switched the same way. The current assumption is that skia m116 (currrent) is a sub-directory, and again have a separate set of build instruction, plus modifying the previous step to build "svg-native-viewer/" with dual cairo and skia backend. - then we can think about adding the COLRv1 difff. Currently, I have "-s 1/2/3" to switch between the 4 hooks at start, and using the layer-glyh toggle key 'z' (which has no effect currently on anything other than ftview), I can toggle the over-writing of svg rendering with COLRv1 rendering, and also over-loaded the palette switching key 'C' (for switching color-blind friendly glyf outline annotation, actually) for COLRv1 palette switching. So I have already got a build that I can turn all these features off, and go back to stock behavior. (the last rpm added in https://github.com/FontVal-extras/binary-archive/) $ ls -l /usr/lib64/librsvg-2.so.2.48.0 -rwxr-xr-x. 1 root root 4396424 Jul 1 01:00 /usr/lib64/librsvg-2.so.2.48.0 $ rpm -ql freetype-demos | grep -E '(bin|lib64)'| xargs ls -l -rwxr-xr-x. 1 root root 36680 Jun 27 01:00 /usr/bin/ftbench -rwxr-xr-x. 1 root root 15800 Jun 27 01:00 /usr/bin/ftchkwd -rwxr-xr-x. 1 root root 679368 Jun 27 01:00 /usr/bin/ftdiff -rwxr-xr-x. 1 root root 48696 Jun 27 01:00 /usr/bin/ftdump -rwxr-xr-x. 1 root root 662920 Jun 27 01:00 /usr/bin/ftgamma -rwxr-xr-x. 1 root root 787768 Jun 27 01:00 /usr/bin/ftgrid -rwxr-xr-x. 1 root root 28152 Jun 27 01:00 /usr/bin/ftlint -rwxr-xr-x. 1 root root 15904 Jun 27 01:00 /usr/bin/ftmemchk -rwxr-xr-x. 1 root root 671080 Jun 27 01:00 /usr/bin/ftmulti -rwxr-xr-x. 1 root root 15792 Jun 27 01:00 /usr/bin/ftpatchk -rwxr-xr-x. 1 root root 750968 Jun 27 01:00 /usr/bin/ftstring -rwxr-xr-x. 1 root root 15856 Jun 27 01:00 /usr/bin/fttimer -rwxr-xr-x
benchmarking and plans for upstreaming the 4-hook patch, and COLRv1 extension.
Hi, The most exciting thing I have done this weekend, is managed to have a procedure/patch-sets to build current skia with max download/clone of about 80MB and max disk usage of about 300MB. Skia takes about 40 minutes to build on dual-CPU (or about 70 minute on single CPU). Without compromising on any functionality. Skia is facinating in both a bad and good way. The official build procedure does a 900MB clone, then fetch 1.6GB swiftshader (mac os x only), 1GB icu (available on Linux), 400MB angle2 (used only windows builds); 5.1GB of thirdparty stuff in total. Then it goes and fetch another 400 MB via emsdk and dump 1.1GB on the hard disk (only useful for building skia for web-assembly). So it eats up 900MB + 5.1GB + 1.1GB ~ 7.1GB before you even start to build any skia source code. !!! If you do shallow clone, only care about linux, and use system libraries as appropriate, you can cut the 7.1GB disk usage down to about 270MB. And the network usage from 600MB + ~2.5GB + 400MB ~ 3.5GB to about 80MB download. So I think we can already start talking about upstreaming the 4-hook diff, because it is now possible to build the whole thing entirely from source without ready-made binary bits from elsewhere, in about an hour. And going towards the COLRv1 extension. Here is what I have in mind in 4 stages: - there are two uncontroversial diffs: adds no_svg /color layer glyph toggle keys to ftgrid, and symbol hiding in rsvg-port.c . The svg hook routines are entirely used via "hook->svg_init", so they don't need to be named at all. - At the moment I use something like this in the Makefile: + $(OBJ_DIR_2)/rsvg-port.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsrvg-port.h + $(COMPILE) $T$(subst /,$(COMPILER_SEP),$@ $<) + + $(OBJ_DIR_2)/rsvg-port-alt.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsvg-port.h + $(COMPILE) -DUSE_ADOBE=1 $T$(subst /,$(COMPILER_SEP),$@ $<) FTCOMMON_OBJ := $(OBJ_DIR_2)/ftcommon.$(SO) \ $(OBJ_DIR_2)/ftpngout.$(SO) \ - $(OBJ_DIR_2)/rsvg-port.$(SO) + $(OBJ_DIR_2)/rsvg-port.$(SO) \ + $(OBJ_DIR_2)/rsvg-port-alt.$(SO) To build the same source file twice, differently, to switch between "rsvg + cairo" and "adobe + cairo". This trick depends on the symbol hiding change. We need something better and more configurable than this? The current assumption is that "svg-native-viewer/" is a sub-directory, and have a separate set of build instructions. - Once we have figured out the "rsvg + cairo" and "adobe + cairo" combination, then, the pair "adobe + (older/any) skia" and " pure skia (m103+)" can be switched the same way. The current assumption is that skia m116 (currrent) is a sub-directory, and again have a separate set of build instruction, plus modifying the previous step to build "svg-native-viewer/" with dual cairo and skia backend. - then we can think about adding the COLRv1 difff. Currently, I have "-s 1/2/3" to switch between the 4 hooks at start, and using the layer-glyh toggle key 'z' (which has no effect currently on anything other than ftview), I can toggle the over-writing of svg rendering with COLRv1 rendering, and also over-loaded the palette switching key 'C' (for switching color-blind friendly glyf outline annotation, actually) for COLRv1 palette switching. So I have already got a build that I can turn all these features off, and go back to stock behavior. (the last rpm added in https://github.com/FontVal-extras/binary-archive/) $ ls -l /usr/lib64/librsvg-2.so.2.48.0 -rwxr-xr-x. 1 root root 4396424 Jul 1 01:00 /usr/lib64/librsvg-2.so.2.48.0 $ rpm -ql freetype-demos | grep -E '(bin|lib64)'| xargs ls -l -rwxr-xr-x. 1 root root 36680 Jun 27 01:00 /usr/bin/ftbench -rwxr-xr-x. 1 root root 15800 Jun 27 01:00 /usr/bin/ftchkwd -rwxr-xr-x. 1 root root 679368 Jun 27 01:00 /usr/bin/ftdiff -rwxr-xr-x. 1 root root 48696 Jun 27 01:00 /usr/bin/ftdump -rwxr-xr-x. 1 root root 662920 Jun 27 01:00 /usr/bin/ftgamma -rwxr-xr-x. 1 root root 787768 Jun 27 01:00 /usr/bin/ftgrid -rwxr-xr-x. 1 root root 28152 Jun 27 01:00 /usr/bin/ftlint -rwxr-xr-x. 1 root root 15904 Jun 27 01:00 /usr/bin/ftmemchk -rwxr-xr-x. 1 root root 671080 Jun 27 01:00 /usr/bin/ftmulti -rwxr-xr-x. 1 root root 15792 Jun 27 01:00 /usr/bin/ftpatchk -rwxr-xr-x. 1 root root 750968 Jun 27 01:00 /usr/bin/ftstring -rwxr-xr-x. 1 root root 15856 Jun 27 01:00 /usr/bin/fttimer -rwxr-xr-x. 1 root root 24400 Jun 27 01:00 /usr/bin/ftvalid -rwxr-xr-x. 1 root root 771352 Jun 27 01:00 /usr/bin/ftview -rwxr-xr-x. 1 root root 6863136 Jun 27 01:00 /usr/lib64/libskia.so -rwxr-xr-x. 1 root root 380352 Jun 27 01:00 /usr/lib64/libskottie.so -rwxr-xr-x. 1 root root 23840 Jun 27 01:00 /usr/lib64/libskparagraph.so -rwxr-xr-x. 1 root root 14984 Jun 27 01:00 /usr/lib64/libsksg.so -rwxr-xr-x. 1 root root 58584 Jun 27 01:00 /usr/lib64/libskshaper.so -rwxr-xr-x. 1 root root 15128 Jun 27 01:00 /usr/lib64/libsktext.so -rwxr-xr-x. 1 root root 37056 Jun 27 01:00 /usr/lib64/libskunicode.so -rwxr-xr-x. 1 root root 252840 Jun 27 01:00
Re: Progress update on adjustment database
On Friday, 21 July 2023 at 07:28:07 BST, Craig White wrote: > ...Those would be one-to-one mappings and many-to-one mappings, respectively. > Would this general solution involve other kinds of GSUB mappings? ... > Even sticking to just many-to-one and one-to-one mappings, ... Having too exclusively a western-european language background might be a blind-side... I haven't followed the conversations too closely, but the 3rd scenario you try to ignore has a very common name: ligature. Ie. Special glyphs for combinations of "fi", "ff", for example. To recap, common usages: One-to-one: alternatesMany-to-one: accent marks, e.g. umlautsOne-glyph-to-many-unicode-characters: ligatures, e.g. "ff", "fi".
4-hook patch (Re: Adobe Native + cairo (Re: Adobe's SVG native as ft2 renderer hook (Re: Bug in rsvg+cairo hook with Nabla?)
I have combined all of the 3 svg hook diff and made a 4-hook patch, it only increases the size of the skia hook patch from about 24k to 34k. I use a -DUSE_ADOBE to make 4 object files from 2 source files, and change the "-s" switch to take a number 1,2,3 for the 3 new hooks. And all 4 now write a single line at svg_init() to say what it is. I imagine the Adobe+cairo part will be extracted and upstream first, as it is not too difficult/slow/hard to build. It is better at rendering some *cough* google color *cough* fonts than librsvg. There is an open issue at my harfbuzz-python-demos repo (where the diff is) collecting the rendering issue numbers I filed at librsvg, Adobe svg, and inkscape. The patch has some harmless colrv1 in the Makefile diff that I don't want to remove; and the small part on static prototype changes to rsvg-port.c/.h can be upstreamed now. (The internal hook routines are only called via the individual hook, so there is no need for their names to be public - hiding them allow me to build 4 object files out of 2 source files, and the result is probably marginally smaller and faster, having fewer public symbols; 3 benefits for one change). Rsvg-port.c/.h probably should be renamed cairo-port.c/.h as it now does both librsvg+cairo and adobe+cairo. (some can go upstream, some are posted for public review/fun, some are too ugly to be shown in public yet - trying to minimise the differences between the 3 "active" branches I have...) Pretty-sure some of you want to hear less often from me now :-). I'll update my system binaries with the 4-hook diff at some point(goes to FontVal-extras/binary-archive/), and carry on with colrv1. On Thursday, 20 July 2023 at 15:01:54 BST, Hin-Tak Leung wrote: It took less than an hour of quick hack to get rid of librsvg and replace it with Adobe Native + its cairo backend from Suziki san. There is a rendering bug filed ashttps://github.com/adobe/svg-native-viewer/issues/185 I said it is between librsvg and skia. The code diff is athttps://github.com/HinTak/harfbuzz-python-demos/blob/master/svg-native/ft2-demos-Adobe-SVG-Cairo.diff (Since I did configure --with-librsvg=no, had to have cairo headers and libs manually... you cam figure out better way of doing that...) So we have 5 svg-hooks now (in history order): librsvg + cairopycairo + librsvg gobject introspection (python)skia m103+Adobe Native + skia (any/older version)Adobe Native + cairo
Palette table (Re: COLRv1 to gray/alpha question (& color-blindness question)
On Wednesday, 19 July 2023 at 05:55:20 BST, Werner LEMBERG wrote: > Different colour schemes are supported; the question is about > defaults. For example, let's assume that a font contains color > schemes A and B, the latter suitable for (most) color-blind people. > Let's further assume that scheme A doesn't render well on a grayscale > device because of identical grayscale values. Does COLRv1 contain any > information to quickly decide which color scheme should be used for > grayscale rendering? I think the palette table already have classifications by dark vs light backgrounds. It might be useful for other attributes like "high-contrast / suitable for visually impaired" and "color-blind-friendly"?
Re: COLRv1 to gray/alpha question (& color-blindness question)
On Thursday, 20 July 2023 at 01:41:51 BST, Alexei Podtelezhnikov wrote: > > > Hin-Tak, > > > > > This is probably both a spec question & a technical question. What is the > > > recommendation for COLRv1 when the rendering target media is not capable > > > of color? > > > > > Alpha is colorless until blended. Therefore any conversion of RGB to > alpha will produce random blending results because assuming black > foreground is wrong even on gray surfaces. Hence, the blending should > be done in color (on gray surface r=g=b), then the final result can be > converted to gray once again for display as above. This is essentially > what should happen in ftgrid/ftview if you choose 8-bit display, > e.g.,"-d 800x600x8". That's not how it is done on my COLRv1-capable ftgrid/ftview. It is an implementation details - I mentioned it twice already, but I'll repeat it a 3rd time: Converting from 32-bit RGBA multi-layered COLRv1 data to 8-bit, I have a choice of telling Skia it is all Alpha or it is all Gray. In the former case, Skia seems to throw way all the RGB data and just collapse the multiple Alpha layers onto one, and draw the foreground Black through the combined Alpha mask. In the 2nd case it is more interesting. As I said, pale solid colors and dark transparent colors renders very differently. If you throw away the alpha data first before collapsing and overlaying the successive glyph layers from 24-bit to 8-bit. Skia seems to think that, since the target media in this case is not transparency-capable, let's throw away the alpha channel first, before drawing the overlayjng layers as solid shades of grays . Probably both approaches are wrong. I am asking that question both in terms of the spec and in terms of implementation details - what is the correct/recommended approach to render multi-layered 32-bit RGBA COLRv1 data to a non-colour target media?
Re: The COLRv1 hook code (Re: FT_Bitmap and FT_BitmapGlyph life cycles)
On Thursday, 20 July 2023 at 09:04:09 BST, Brad Neimann wrote: > > Perhaps it is easier just to show you what I have - this is already > > functional and I can even switch COLRv1 palettes in ftgrid > > (screenshots the usual place). > …and where is this ‘usual place’? I can’t see screenshots anywhere. They are being added to the bottom of: https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure I have a COLRv1-emhanced ftgrid where the "C" key (normally for switching colours for glyph outlines in glyf mode) which cycles through the palettes - it also changes the status line on the side saying what palette number it is on. Still on having freetype demos telling skia to do stuff and receiving rendered coloured bitmaps back :-). Just moving further on from skia rendering SVG to skia rendering COLRv1. Some of the 7 palettes are obviously for dark backgrounds - I probably should have this info out. How clear do you see things being interesting for palettes 0 to 6?
Adobe Native + cairo (Re: Adobe's SVG native as ft2 renderer hook (Re: Bug in rsvg+cairo hook with Nabla?)
It took less than an hour of quick hack to get rid of librsvg and replace it with Adobe Native + its cairo backend from Suziki san. There is a rendering bug filed ashttps://github.com/adobe/svg-native-viewer/issues/185 I said it is between librsvg and skia. The code diff is athttps://github.com/HinTak/harfbuzz-python-demos/blob/master/svg-native/ft2-demos-Adobe-SVG-Cairo.diff (Since I did configure --with-librsvg=no, had to have cairo headers and libs manually... you cam figure out better way of doing that...) So we have 5 svg-hooks now (in history order): librsvg + cairopycairo + librsvg gobject introspection (python)skia m103+Adobe Native + skia (any/older version)Adobe Native + cairo
The COLRv1 hook code (Re: FT_Bitmap and FT_BitmapGlyph life cycles)
Perhaps it is easier just to show you what I have - this is already functional
and I can even switch COLRv1 palettes in ftgrid (screenshots the usual place).
Basically it works the same ways as svg hooks: the preset slot hook calculates
the bound boxes, while the render hook actually draws to the bitmap.
In this case, I have a FT_Load_Glyph_Extended() which calls FT_Load_Glyph(),
but also call FT_Get_Color_Glyph_ClipBox_Extended(), which is a skia routine
which does FT_Get_Color_Glyph_ClipBox() but also if that fails, tries to union
all the layers to calculate a skia bound box. I should convert back to override
the FT_Load_Glyph() bound values but haven't (yet).
Then I have a "FT_Glyph_To_Bitmap_Extended()" which also calls
"FT_Glyph_To_Bitmap()", but then overwrite and draws to its bitmap with skia
before returning. I'd like to not call "FT_Glyph_To_Bitmap()" but just do
'FT_New_Glyph()' on my own, but that always crashes. why?
'...' and '...' are deleted parts too ugly that will hurt your eyes if you see
them :-). #include "skia-colrv1-stub.h"
#include FT_COLOR_H
#include FT_BITMAP_H
#include "include/core/SkRect.h"
#include "include/core/SkBitmap.h"
#include "include/core/SkCanvas.h"
#include "freetype/internal/ftobjs.h"
#include "skia-src-ports-SkFontHost_FreeType_common_colrv1.h"
/* in skia-src-ports-SkFontHost_FreeType_colrv1.cpp */
SkRect FT_Get_Color_Glyph_ClipBox_Extended( FT_Face fFace,
FT_UInt base_glyph,
FT_ClipBox* clip_box );
FT_Bool isCOLRv1(FT_Face face,
FT_UInt glyph_index) {
if (FT_IS_SCALABLE(face)) {
FT_OpaquePaint opaqueLayerPaint{nullptr, 1};
if (FT_Get_Color_Glyph_Paint(face, glyph_index,
FT_COLOR_INCLUDE_ROOT_TRANSFORM, )) {
return true;
}
}
return false;
}
void skia_colr_set_current_palette( FT_Face face,
FT_UInt palette_index ) {
... = ... palette_index;
}
FT_UShort skia_colr_get_current_palette( FT_Face face ) {
... ;
}
FT_Error FT_Load_Glyph_Extended( FT_Face face,
FT_UInt glyph_index,
FT_Int32 load_flags ) {
if ( isCOLRv1( face, glyph_index)
&& (load_flags & FT_LOAD_COLOR)
) {
FT_ClipBox clipBox;
SkRect bounds = FT_Get_Color_Glyph_ClipBox_Extended( face,
glyph_index,
);
... keep bounds ...
}
FT_Error res = FT_Load_Glyph( face, glyph_index, load_flags );
return res;
}
FT_Error FT_Glyph_To_Bitmap_Extended( FT_Glyph* the_glyph,
FT_Render_Moderender_mode,
const FT_Vector* origin,
FT_Bool destroy ) {
...
FT_Error res = FT_Glyph_To_Bitmap( the_glyph, render_mode, origin, destroy );
... retrieve bounds ...
if ( face && bounds ) {
FT_UInt glyph_index = face->glyph->glyph_index;
/* General variables. */
int width = ceil(bounds->right()) - floor(bounds->left()); //bounds.width(); // fRight minus fLeft
int height = ceil(bounds->bottom()) - floor(bounds->top()); //bounds.height(); // fBottom minus fTop
int x = floor(bounds->left());
int y = floor(bounds->top());
int size = width * height * 4;
FT_Error error;
FT_Memory memory = lib->memory;
FT_Glyphgbitmap = NULL;
if (isCOLRv1(face, glyph_index) && (FT_GLYPH_FORMAT_BITMAP == (*the_glyph)->format))
{
FT_BitmapGlyphbitmap = (FT_BitmapGlyph)(*the_glyph);
if ((bitmap->bitmap.pixel_mode == FT_PIXEL_MODE_BGRA) || (bitmap->bitmap.pixel_mode == FT_PIXEL_MODE_GRAY)) {
SkBitmap dstBitmap;
dstBitmap.setInfo(SkImageInfo::Make(bitmap->bitmap.width, bitmap->bitmap.rows,
((bitmap->bitmap.pixel_mode == FT_PIXEL_MODE_BGRA) ?
kBGRA__SkColorType : kGray_8_SkColorType),
kPremul_SkAlphaType),
bitmap->bitmap.pitch);
dstBitmap.setPixels(bitmap->bitmap.buffer);
SkCanvas canvas(dstBitmap);
canvas.clear(SK_ColorTRANSPARENT);
canvas.translate( -x, -y );
bool haveLayers = skia_colrv1_start_glyph(,
face, glyph_index,
FT_COLOR_INCLUDE_ROOT_TRANSFORM);
fprintf(stderr, "**bounds %d %d %d %d - SkRect Max\n",
x,
-y,
width,
height);
fprintf(stderr, "**bounds %d %d %d %d - Not skia\n",
bitmap->left,
Re: Adobe's SVG native as ft2 renderer hook (Re: Bug in rsvg+cairo hook with Nabla?
Adobe's SVG native is half way between librsvg and skia's svg rendering. Screenshots of 3 at https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure And diff against the skia-port code in the ../svg-native/ directory above, and a lot more screenshots. It shouldn't be hard to make a adobe+cairo version from the librsvg+cairo version, if you see the adobe+skia version diff against pure skia (skia+skia svg module).
Adobe's SVG native as ft2 renderer hook (Re: Bug in rsvg+cairo hook with Nabla?
On Wednesday, 19 July 2023 at 05:07:42 BST, Werner LEMBERG wrote: > >> ... please post a link to the report if you do so :-) > https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 > By the way, is there any progress whether Adobe's compact SVG native > viewer library can be used as a FreeType hook? It comes with a Cairo > backend, among others... > https://github.com/adobe/svg-native-viewer The cairo backend was contributed by our Suzuki San (added CC). The answer to your question is yes :-). I chose the skia backend to use (ie dropping skia's own svg parser, but still use skia graphics) as svg renderer hook. I built svg native with dual skia and cairo backends, and run its two backend test programs against the Nabla svg. The results only differ by edges.The result is in the middle of librsvg and skia's own svg renderer.Half of the resulting figure is black. The new Adobe-skia hook code differs from the skia+skiasvg code by only about 5 lines plus header changes. A possible Adobe+cairo code differs from the librsvg+cairo code maybe by similar amount. I'll put some screenshots up online, and you can see what I mean by its being half-black :-).
Re: COLRv1 to gray/alpha question (& color-blindness question)
On Wednesday, 19 July 2023 at 15:27:20 BST, Alexei Podtelezhnikov wrote: > Hin-Tak, > This is probably both a spec question & a technical question. What is the > recommendation for COLRv1 when the rendering target media is not capable of > color? > Are you asking about RGB to gray conversion? There are multiple specs with > slightly different formulas and barely noticeable differences, with and > without gamma correction. I’m is all pretty arbitrary without settled > consensus. > Gray = 0.3R + 0.6G + 0.1B > is good enough. I am talking about 32-bit RGBA to 8-bit gray conversion, and I gave two examples/directions - throwing away the RGB part (and use the alpha channel as a mask on the current foreground colour), or throw away the A part, and doing 24-bit colour to gray conversion like you suggested (or even just gray = (r+g+b)/3). There is probably also a complication in the 2nd case, for layered glyphs - do you throw away the alpha channel first and stack the resulting solid colours/gray on top of one another, or do the full 32-bit rendering, then throw away the alpha channel and collapse the 24-bit? Werner also raised an interesting point - there is provision for palette on dark background vs light background I think, but is there a way of indicating some palettes are colour-blind-friendly? In the western world, it can be as bad as 1 in 30 male Caucasians being colour-blind.
Re: FT_Bitmap and FT_BitmapGlyph life cycles
On Wednesday, 19 July 2023 at 05:42:32 BST, Werner LEMBERG wrote: > > How to throw away the bitmap resulting from running > > FT_Glyph_To_Bitmap(), and replacing it with a new one that may be > > one pixel large or smaller in width and/or height? > It's not exactly clear to me what you want to do, but what about using > `FT_New_Glyph` and/or `FT_Glyph_Copy`? I have indeed looked at FT_New_Glyph(). It returns a FT_BitmapGlyph with zero width/height. I tried after FT_New_Glyph with: FT_Memory memory = library->memory; FT_MEM_ALLOC( bitmap->bitmap.buffer, mysize); to make it bigger, but it always segfaults. Maybe if I stare at the code for longer it will come to me :-).
Re: COLRv1 to gray/alpha question (& color-blindness question)
On Wednesday, 19 July 2023 at 05:19:40 BST, Werner LEMBERG wrote: > > I’m colour-blind, but not sure I understand what you’re asking > > here. None of the colour fonts on Google Fonts seem obviously > > difficult to read for me. > Let's assume that you can't discern colors A and B, where both map to > exactly the same gray value C (or to almost identical values). If a > glyph uses those two colours exclusively, you will have problems with > both a colour and a gray-level version of it. Population health statistics - a few percent of Caucasian males are red-green colour-blind. I guess Brad is one of them. So I draw a pink smiley face on a pale green background, you won't be able to tell there is a smiley face. If we are talking about text fonts, using colour fonts to annotate Arabic for proper pronunciation of passages from the Quran... is it possible to intentionally create a font that would cause colour blind non-native people to mis-pronounce certain words and create offences / blasphemy? :-).
FT_Bitmap and FT_BitmapGlyph life cycles (Re: COLRv1 to gray/alpha question (& color-blindness question)
The technical question. I have worked out how to "hijack" the current system-
basically wrapping "FT_Glyph_To_Bitmap()" with my "*_Extended()" version, which
calls "FT_Glyph_To_Bitmap()" then over-write the bitmap with Skia's help before
returning.
Since this sort of depends on the font being regarded as 'coloured', so I was
over-writing SVG rendering in the dual-table font (the rsvg bug turns out to be
a blessing - I am overwriting a "wrong" SVG-generated b/w RGBA buffer with
COLRv1 colours, so I know it is working when the bug "disappears"), and
overwriting a 8-bit gray buffer with grays in a modified font without SVG
table. But ideally I'll like to throw it away and do my own things - this is
most important when the dimension of COLRv1 rendering is one pixel different
from glyf or SVG rendering.(It is rare but it does happen). I don't seem to be
about to create my own bitmap - it always crashes - so my question is exactly
that:
How to throw away the bitmap resulting from running FT_Glyph_To_Bitmap(), and
replacing it with a new one that may be one pixel large or smaller in width
and/or height?
On Wednesday, 19 July 2023 at 05:01:50 BST, Hin-Tak Leung
wrote:
Hi,
This is probably both a spec question & a technical question. What is the
recommendation for COLRv1 when the rendering target media is not capable of
color?
OT-SVG probably has its rules inherited from SVG; or at least, it doesn't feel
too odd to use SVG solely for color output, and glyf/CFF for 8-bit gray with
anti-aliasing.
With COLRv0, the decisions of solid colours vs gray with anti-aliasing
semi-transparent edges probably isn't too hard either.
I have finished adding COLRv1-capability to ft2-demos (that potentially means
any FreeType-based system/software is then COLRv1-able), but was faced with two
interesting choices:
- COLRv1 layers have alpha channels too, so one way of doing it is to throw
away all the colours, and collapse all the alpha layers and draw the foreground
colour (ie black) through the alpha channel.
- throw away the alpha channels, convert RGB to gray levels.
The two differ quite significantly if you have dark but transparent colours vs
pale but solid colours.
In terms of implementation details, some systems might eventually choose to
"lie" about legacy (non-colour) fonts as all having exactly 1 layer with a
default palette of B/W, to simplify and unify APIs of accessing colour-layered
and non-colour fonts?
A somewhat related question - colour fonts are used beyond emoji's. While there
are 5 kinds of emoji fonts now, and most people are using one of 4... but if
you check Google Fonts, there are 10 colour fonts, one is emoji, but 6 are
Arabic (useful for annotating the Quran...) and 3 are Latin. So there are
intentions for text fonts. A few percents of western male population is
color-blind. Colour-blindness is one of the most common eye problems, after
short-sightedness :-).
Screenshots at the bottom half of the web page below, and I'll continue the
more technical stuff on freetype-devel.
https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure
COLRv1 to gray/alpha question (& color-blindness question)
Hi, This is probably both a spec question & a technical question. What is the recommendation for COLRv1 when the rendering target media is not capable of color? OT-SVG probably has its rules inherited from SVG; or at least, it doesn't feel too odd to use SVG solely for color output, and glyf/CFF for 8-bit gray with anti-aliasing. With COLRv0, the decisions of solid colours vs gray with anti-aliasing semi-transparent edges probably isn't too hard either. I have finished adding COLRv1-capability to ft2-demos (that potentially means any FreeType-based system/software is then COLRv1-able), but was faced with two interesting choices: - COLRv1 layers have alpha channels too, so one way of doing it is to throw away all the colours, and collapse all the alpha layers and draw the foreground colour (ie black) through the alpha channel. - throw away the alpha channels, convert RGB to gray levels. The two differ quite significantly if you have dark but transparent colours vs pale but solid colours. In terms of implementation details, some systems might eventually choose to "lie" about legacy (non-colour) fonts as all having exactly 1 layer with a default palette of B/W, to simplify and unify APIs of accessing colour-layered and non-colour fonts? A somewhat related question - colour fonts are used beyond emoji's. While there are 5 kinds of emoji fonts now, and most people are using one of 4... but if you check Google Fonts, there are 10 colour fonts, one is emoji, but 6 are Arabic (useful for annotating the Quran...) and 3 are Latin. So there are intentions for text fonts. A few percents of western male population is color-blind. Colour-blindness is one of the most common eye problems, after short-sightedness :-). Screenshots at the bottom half of the web page below, and I'll continue the more technical stuff on freetype-devel. https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure
Re: Bug in rsvg+cairo hook with Nabla? (Re: another small patch for ft2-demos, and other stuff.
On Monday, 17 July 2023 at 05:46:37 BST, Werner LEMBERG wrote: > ... please post a link to the report if you do so :-) https://gitlab.gnome.org/GNOME/librsvg/-/issues/997 Inkscape always shows opaque black. (That's why I assumed that Google folks shipped inferior SVG table in their COLRv1 fonts) . Skia, and right after I upload it, my webkit gtk based browser (a small c# thing I wrote, side-line of the fontval web-browser code...) rendered the glyph layers inline, so webkit can get the colours as an svg too.
Re: Bug in rsvg+cairo hook with Nabla? (Re: another small patch for ft2-demos, and other stuff.
On Monday, 17 July 2023 at 05:46:37 BST, Werner LEMBERG wrote: > > [...] I seem to have found a problem with the rsvg/cairo-based hook > > with the Google Nabla color font. > > > > [...] I found that rsvg+cairo hook renders it B/W [...]. Strangely > > enough, with the skia-based hook, I see the expected color look. > > [...] this seems to suggest that the SVG in this font is a bit weird > > and/or rsvg+cairo can't handle it. > Does this happen with the latest 'librsvg' version (current is > 2.56.90)? If so, please report it to the maintainers so that they can >.fix it. The used set of SVG commands in OpenType is very limited, and > if 'librsvg' can't handle that correctly, it is a serious bug – and > please post a link to the report if you do so :-) I have 2.56.2 which is close enough to latest. Will give 2.56.90 a try when I finish the COLRv1 hook. The font uses semi-transparent and non-linear(?) gradients and SVG things that matches the COLRv1 functionality so probably pushes some corners, but librsvg supposedly supports SVG 2... 2.56.2 is close enough to current, so the question is whether they fixed it between 2.56.2 and 2.56.90 :-).
Re: QT6 build of ftinspect bit-rotten?
On Monday, 17 July 2023 at 05:52:36 BST, Werner LEMBERG wrote:
> > Btw, anybody done QT6 build of ftinspect lately?
> Well, looking into `src/ftinspect/{meson.build,CMakeLists.txt}` I only
> see build support for Qt5. Apparently, Qt6 support was tested
> experimentally only.
> Charlie, can you comment, please?
There are some conditionals "if QT_VERSION(6, 0, 0)" scattered through out the
code, and QT6 provides a qt5compat library, so I though I'll give it a try. The
qt6 support is WIP I guess. Maybe bombing out is better (ie where the API is
known to change, just bomb out with '#error "qt6 not yet supported"' ), but I
guess Charlie never foresaw somebody bypassing meson/cmake and try to build
ftinspect without using either :-).
Re: rsvg vs skia comparison (the actual skia based ft2-demo ot-svg renderer hook code diff
Missing API - same missingness as Skia's SVG parser before m103, as far as I
can see. (Or maybe I didn't look thorough enough :-)).
Interesting to have another svg library, I guess. Associated with tizen so
probably backed by Samsung, and the non-google/apple mobile industry.
On Monday, 17 July 2023 at 12:43:07 BST, Vincent Torri
wrote:
Hey
Have you looked at ThorVG ?
https://github.com/thorvg/thorvg
Vincent
On Sun, Jul 16, 2023 at 7:49 PM Werner LEMBERG wrote:
> One question, is c++ built libfreetype binary completely compatible?
> It seems the opposite is (c++ built ft2-demos can use c-built
> freetype) is.
I think that in general it is possible to use C libraries as-is in C++
but not vice versa.
> Basically I am thinking of doing a
>
> FT_Load_Glyph_Extended(face, glyph_id, flags) {
> if (glyph_id not COLRv1)
> return FT_Load_Glyph(); /* pass it on */
>
> ... do stuff and fill in a color bitmap and it's size/offset..
> }
This might work in the demo programs, yes.
Werner
Bug in rsvg+cairo hook with Nabla? (Re: another small patch for ft2-demos, and other stuff.
On Sunday, 16 July 2023 at 07:02:50 BST, Werner LEMBERG wrote: > > That fundamentally means it is not possible to switch the renderer > > hook on a per current glyph level, keeping the current face? >.I don't think so – who wants that except weird FreeType demo > programs? :-) > Moazin, please comment. I have started on the colrv1 hook, and surprise, I seem to have found a problem with the rsvg/cairo-based hook with the Google Nabla color font. This is a COLRv1 color font which also has a SVG table. Basically most of the COLRv1 demos Google folks blog about are with this font. I found that rsvg+cairo hook renders it B/W, but I had always assumed that Google ships an inferior SVG table, since the font is mainly for demo'ing COLRv1. Strangely enough, with the skia-based hook, I see the expected color look. I haven't even started on COLRv1 at all, this seems to suggest that the SVG in this font is a bit weird and/or rsvg+cairo can't handle it. Anyway, for your purpose, you just need to know that another svg rendering hook can show color, but rsvg+cairo does not. I put the screenshots up athttps://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure , plus illustration on the pale edge pixels difference I mentioned earlier. Back to COLRv1. (I should just remove the SVG table from Nabla to concentrate on the COLRv1 functionality...)
QT6 build of ftinspect bit-rotten? (Re: skeletal makefile for ftinspect (Re: Future of autotools)
Btw, anybody done QT6 build of ftinspect lately?When I was writing the makefile, I had to install some qt5*-devel packages. I did some qt3/qt4 stuff a long time ago, so I kept those, but uninstalled most of qt5-dev stuff when I see qt6 being installed as part of half-yearly upgrade. I am on gnome, so kde stuff is really around for occasional curiosity. I just checked kde is still qt5... and only about 2 GUI applications I use depends on QT6 libraries. Anyway, I see some QT6 compatibility code in ftinspect, but they seem to have gotten bit-rotten / still WIP? On Monday, 17 July 2023 at 00:22:05 BST, Hugh McMaster wrote: On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote: > The pkg-config interface should take care of everything easily. Debian and > Ubuntu have the relevant qt5 pkg-config files. Other distributions should too. Does pkg-config give the information for the pathname of moc? (the original question by Hin-Tak was asking about the appropriate path to use moc command) In my understanding, pkg-config is primarily designed to provide the information to compile & link the libraries, not designed to provide the information about the binary executable commands. Extra information beyond the standard prefix, sysconfdir, libdir etc. is package dependent. In this case, Qt5Core.pc has a variable that provides the path to a directory containing binaries such as moc.
Re: skeletal makefile for ftinspect (Re: Future of autotools)
Yes, the moc location on fedora 38 can be queried with:
pkg-config Qt5Core --variable=host_bins
If this works correctly on other systems, we should set
MOC=`pkg-config Qt5Core --variable=host_bins`/moc
Or put PATH=${PATH}:`pkg-config Qt5Core --variable=host_bins` and MOC=moc ?
I am more inclined towards the former, few surprises.
On Monday, 17 July 2023 at 00:22:05 BST, Hugh McMaster
wrote:
On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote:
> The pkg-config interface should take care of everything easily. Debian and
> Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.
Does pkg-config give the information for the pathname of moc?
(the original question by Hin-Tak was asking about the
appropriate path to use moc command)
In my understanding, pkg-config is primarily designed to
provide the information to compile & link the libraries,
not designed to provide the information about the binary
executable commands.
Extra information beyond the standard prefix, sysconfdir, libdir etc. is
package dependent.
In this case, Qt5Core.pc has a variable that provides the path to a directory
containing binaries such as moc.
Re: Strange hinting of precomposed character
On Sunday, 16 July 2023 at 07:54:11 BST, Brad Neimann wrote: > ...Can anyone explain what’s > happening here? I would expect that, if the diacritic is to be hinted as > a horizontal bar, that would occur only at the smallest sizes, and would > equally affect the combining diacritic too. Somebody more knowledgeable can correct me, but I think combining diacritics happens with: Outline1 -> hinted bitmap1Outline2 -> hinted bitmap2 Bitmap output = hinted bitmap1 + hinted bitmap2 positioned at grid-fitted (ie another "hinting") offsets (Actually, I think it happens in the opposite order: the grid-fitted offsets are calculated first) compared to a single glyph with two sets of outlines, where the outlines are hinted together.
Re: rsvg vs skia comparison (the actual skia based ft2-demo ot-svg renderer hook code diff
On Sunday, 16 July 2023 at 07:13:20 BST, Werner LEMBERG wrote:
> > I added a "-s" command line option to both ftview and ftgrid to swap
> > rsvg out with skia and run the same binary twice, one with "-s" and
>.> one without, just to look at them side by side. Fixed the pixel
> positioning discrepancies. Patch posted online below
>.>
> >
> >https://github.com/HinTak/harfbuzz-python-demos/blob/master/skia-adventure/ft2-demos-skia-m110.diff
> Very nice! Of course, it would be necessary to properly adjust the
> build support to find Skia the 'official' way before I can add this to
> the `freetype-demos` repository. Too bad that building Skia is so
> demanding.
Yes, that's completely understood. There are at least two problems of
committing the diff as is - the use of prebuilt and unofficial binaries, and
that skia is moving so fast (the patch has already bit-rotten between m110 and
m116/main). Both of which can be solved by having skia as a git submodule and
locking it at a particular state; then we have a 3rd problem, which is that
building skia is a 1GB clone, which then wants to clone another 1GB+ of
dependencies before starting. I'd like to give it a try eventually to trim it
down, do shallow clones etc, later, maybe one cold winter holiday with nothing
to do :-).
Since this is just adding a "-s" switch (and 100MB+ disk usage), I have rebuilt
my system's ft2-demos to have the feature semi-permanently.
https://github.com/FontVal-extras/binary-archive/commit/8c7d17bc7423e4371e29ac7074ea6e8ec530cf98
One question, is c++ built libfreetype binary completely compatible? It seems
the opposite is (c++ built ft2-demos can use c-built freetype) is. In fact I
was running 2.13.1 c++ built ft2-demo against the system's c-built freetype
2.13.0 briefly, before I rebooted.But I don't want to install the matching
c++-built libfreetype (people thinking of grabbing my ft2-demos rpm - please
DON'T grab the matching libfreetype one, take the one from the commit before
that! The matching one is just a built-set for archive purpose...)
I am thinking of stuffing skia underneath for COLRv1 too. Added the COLRv1
detection python code to freetype-py yesterday.
Basically I am thinking of doing a
FT_Load_Glyph_Extended(face, glyph_id, flags) { if (glyph_id not COLRv1)
return FT_Load_Glyph(); /* pass it on */
... do stuff and fill in a color bitmap and it's size/offset..}
Since ftgrid has only one FT_Load_Glyph() call (in fact most of ft2-demos are
like that), this is the least intrusive way of adding it. It is actually mostly
very similar to how the SVG renderer hook is done.
I think the SVG renderer hook is somewhat equivalent to this:
FT_Load_Glyph_Extended(face, glyph_id, flags) { If (not SVG) return
FT_Load_Glyph();
If (svg_init() not yet run once) run svg_init(); /* once ever */
svg_preset_slot(); if (flags without LOAD_RENDER) return;
svg_render();
/* svg_free() is never used... */}
Except svg_renderer() and svg_preset_slot() wants to keep some private state
persisting and sharing between successive calls.
I actually like some part of skia better than cairo: skia objects are shared
pointers and internally reference-counted, so they just go away when you stop
using them. No need to do "cairo_destroy_context(ctx);" etc. In fact the Google
folks extended some of freetype structs to automatically do that too, something
like:
convenientFT_Face = unique_ptrFT_Face_Done>();
So that "FT_Face_Done" is called automatically when "convenientFT_Face" goes
out of scope.
Quite clever. If only skia is easier to build and use!
Hin-Tak
Re: ftbench update: make integrated
Cool. You should use "$(CC)" instead of "gcc" explicitly. Read the "implicit variables" section in the GNU manual regarding what built-in variables are there. Ideally you should use "$(LINK_CMD)" there too. That is defined towards the top of the Makefile. Good you have found "echo". You know you can "echo $(CC)" etc to display what values those variables take, too? The first rule likewise should be "$(COMPILE)" to fit in to the rest, in terms of style. Certainly very well done snd congratulations you have found your way around libtool and make! On Friday, 14 July 2023 at 14:26:28 BST, Ahmet Göksu wrote: Thanks a lot, it works now. I have updated the makefile like: # Build ftbench.o $(FTBENCH_OBJ): $(FTBENCH_SRC) @echo "Building ftbench object..." $(CC) $(INCLUDES) -c $< -o $@ # Build ftbench $(FTBENCH_BIN): $(FTBENCH_OBJ) @echo "Linking ftbench..." $(LIBTOOL) --mode=link gcc -L$(LIB_DIR) -lfreetype $< -o $@ @echo "Built." but at the second rule, to produce this line: $(LIBTOOL) --mode=link gcc, i used gcc instead of $(CC) which is an also a libtool. Is it a wrong approach? i remember something about not to using gcc in past mails. Best,Goksugoksu.inOn 12 Jul 2023 22:17 +0300, Hin-Tak Leung , wrote: (Please keep the CC to freetype-devel) libtool is also heavily in the GNU family, although mainly maintained by the people at https://sourceware.org/ , I think. (ancient time people politics...) . http://www.gnu.org/software/libtool/ is also quite well-maintained. You actually don't need to know much about libtool, really; it mostly just launches other commands. i.e. what follows " libtool —mode=compile " is mostly a valid compiler command, you should be able to cut and paste it and run it directly. If it does not work, variable expansions inside your makefile is wrong. So what follows --mode=compile should mostly looks like gcc source1.c -o source1.o or something similar. The "libtool —mode=link " mode is mostly a linker command too. So it should looks like gcc -Llocation1 -Llocation2 -lone -ltwo -Iinclude1 -Iinclude2 1source1.o source2.o source3.o -o binary1 The only difference from a properly valid linking command vs what follows "libtool —mode=link " is that some *.la files happens instead of the equivalent *.so or *.a . For example, I am doing ft2-demo builds at the moment, and the screen echos this commands it is running: libtool --mode=link ... /home/Hin-Tak/git-others/freetype2/objs/libfreetype.la ... in the middle. and it is followed by this information in the next line: libtool: link: ... /home/Hin-Tak/git-others/freetype2/objs/.libs/libfreetype.so ... What follows "libtool: link: " is the actual compiler command it is running. That you should be able to cut and paste and run directly and it should execute without error. Anyway, this is just a quick tutorial... there is no substitute for actually reading the manual :-). They are quite well written, as I keep saying :-). Your "libtool --mode=link " line below is obviously wrong. It is missing the actual compiler name (gcc/cc/clang) itself. On Wednesday, 12 July 2023 at 16:22:04 BST, Ahmet Göksu wrote: thanks a lot, Make works good actually :) the problem i am facing is linking the .o file to binary (even by terminal commands, manually). like: libtool —mode=link ftbench.o -o ftbench some binary, flag or parameter needed i think. Thanks, Goksu goksu.in On 12 Jul 2023 6:12 PM +0300, Hin-Tak Leung , wrote: The GNU Make manual is quite useful - and very well-written too. Go and download it and sit down for an afternoon, away from the keyboard, read sections of it. Good indexes and cross-references too. I think you probably want to do "make -n", for make to just print out what it will do, and just read what all the variables expanding to. It is really just Goal : dependencies How-to-make-goal-from-dependencies There is a section on implicit variables ($@, $^, $<, $CC) and patterns and substitutions, (usage of subst). As I said, it is very well written, and explains a lot of things much better than I or anybody could ever do in a short e-mail :-). On Wednesday, 12 July 2023 at 22:58:47 GMT+8, Ahmet Göksu wrote: actually i am stucked in linking. cc generates object file well but here i am missing something: $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) tried also this $(LIBTOOL) --mode=link $(CC) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) and this $(LIBTOOL) --mode=link $(CC) $^ -o $@ Best, Goksu goksu.in On 12 Jul 2023 5:33 PM +0300, Hin-Tak Leung , wrote: On Wednesday, 12 July 2023 at 21:25:05 GMT+8, Ahmet Göksu wrote: > but i am stucked to binary. $(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) $(LIBTOOL) --mode
rsvg vs skia comparison (the actual skia based ft2-demo ot-svg renderer hook code diff (Re: Success - Re: Skia-based ot-svg renderer hook to freetype)
I added a "-s" command line option to both ftview and ftgrid to swap rsvg out with skia and run the same binary twice, one with "-s" and one without, just to look at them side by side. Fixed the pixel positioning discrepancies. Patch posted online below. I think skia is marginally faster. Also, looking at them side by side, it seems that rsvg+cairo has a tendency of having very pale extra edge pixels compared to Skia's. It is almost as if Skia's svg rendering has a grid-fit/auto-hinting option. As a result, skia-generated color bitmaps has a cleaner look, and often a pixel narrower and shorter too. The "cleaner" look might be a side-effect of optimization - doing rendering at 1/4 pixels precision or color quantization to 6x6x6 club, for example, can probably go faster than arbitrary precision in color and positioning. The patch is as below. I don't advertise it, but FontVal-extra/binary-archive on github have rpm's built for fedora 38 I used myself, and have the fontval diff patched in etc. I am thinking of rebuilding my system ftview/frgrid with this patch. If it happens, the rpms will land there. On Thursday, 13 July 2023 at 04:04:38 BST, Hin-Tak Leung wrote: > will probably post this up at > https://github.com/HinTak/harfbuzz-python-demos/ under a new directory > "skia-adventure" and write there. Thanks for reading this far :-). >
Re: Future of autotools
On Friday, 14 July 2023 at 03:53:10 GMT+8, Werner LEMBERG wrote: > Well, this is not how Meson support is currently set up in `freetype-demos`: in `subprojects/freetype.wrap`, HEAD of FreeType's > git repository is used. This is absolutely necessary while developing > since we regularly use new, not-yet-published features of FreeType in > the demo programs. > I don't mind if someone is going to modify the Meson stuff to move > this requirement to an easy-to-use equivalent to `make devel`. Then a > standard Meson build could be against a system-installed FreeType Okay, that's a fair point - features simultaneously getting added in both freetype2 and tested in freetype2-demos. I probably will propose identifying some of the demos that don't (currently) needs private headers to have a "build-against-system" option. I mean cosmetic things like adding a toggle from one tool to another shouldn't need dev freetype. Hin-Tak
another small patch for ft2-demos, and other stuff.
Hi Werner,
another small patch for ft2-demos. Should be obvious/trivial. BTW, accumulated
patches get reposted when I post the next one, so there is no need to rush.
I had a quick look at swapping the renderer hook on the fly. It seems that it
is set when the module is loaded (i.e. the first font that needs it, I think),
and I actually cannot see when it is unloaded, though it says the svg_free hook
is run when the module is unloaded (which is never...), and when the module is
unloaded, all the font faces it is associated with is freed.
That fundamentally means it is not possible to switch the renderer hook on a
per current glyph level, keeping the current face?
That said, I'd probably like the ability to swap at restart. (i.e. a new
command line switch).
Not sure about merging the skia-based renderer hook. Skia is definitely moving
very fast and the diff has already bit-rotten. I did it with a m110 binary
bundle from the java-skia folks, and one of the headers I use has already
changed location in m116/HEAD . The addition will bit-rot very fast. OTOH, it
is good to have alternatives.
Hin-Tak
From 0bded4e867c1db795130eb8d084bff3e5495c698 Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Thu, 13 Jul 2023 18:30:05 +0100
Subject: [PATCH] rsvg-port.c: Correct usage of FT_Bool vs gboolean comparison
`TRUE' in this context is from glib headers (glib-2.0/glib/gmacros.h)
imported indirectly from rsvg headers. It should not be used
for comparison with FT_Bool types. Other usages of `TRUE/FALSE' in this
file is okay.
Signed-off-by: Hin-Tak Leung
---
src/rsvg-port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/rsvg-port.c b/src/rsvg-port.c
index ff5b164..959afe9 100644
--- a/src/rsvg-port.c
+++ b/src/rsvg-port.c
@@ -437,7 +437,7 @@
/* If a render call is to follow, just destroy the context for the */
/* recording surface since no more drawing will be done on it. */
/* However, keep the surface itself for use by the render hook.*/
-if ( cache == TRUE )
+if ( cache )
{
cairo_destroy( rec_cr );
goto CleanLibrsvg;
--
2.41.0
Re: Future of autotools
On Thursday, 13 July 2023 at 22:46:38 GMT+8, Hugh McMaster wrote: > If we are going to overhaul the build system, I’ve long wanted to have > FreeType demos build as a separate package that links against a > system-installed FreeType library (not the source directory). I second that! I think only ttdebug definitely wants to link against freetype at the source/private header level. You can see my skeletal makefile for ftinspect that it is using system freetype and that seems to work okay. I think the majority of ftdemo can work against a stock system freetype+public header. > That’s how we detect python3 and librsvg (although I wish there were a > lighter library available). That said, there’s certainly an argument for > alternative approaches. I don't know if rsvg does its own xml parsing or farms it off to libxml2 (for example), but the task of xml parsing itself is a library of its own in every programming language. The Java library for SVG, batik, is quite large too. rsvg + cairo is about 7MB shared libraries; linking skia in adds about 25MB static - I suspect all the svg parsing in rsvg if done in static might come to a similar size. I have a small impression that skia-enabled ft2-demo is marginally faster than rsvg+cairo, but this is probably something for our GSoC students to measure/confirm/dispute :-).
Re: skeletal makefile for ftinspect (Re: Future of autotools)
Besides the obvious (LDFLAGS and CXXFLAGS), I wonder what's correct way to detect the qt moc tool? It is /usr/bin/moc-qt5 /usr/lib64/qt5/bin/moc /usr/lib64/qt5/bin/moc-qt5 on my system (fedora 38). They are all the same. "/usr/lib64/qt5/bin/moc" is probably canonical, instead of "/usr/bin/moc-qt5" I put down in ftinspect.mk . Because /usr/lib64/qt-3.3/bin/moc /usr/lib64/qt4/bin/moc /usr/lib64/qt5/bin/moc are the other versions I have. On Thursday, 13 July 2023 at 04:04:54 BST, suzuki toshiya wrote: Good, I was just trying to update configure.raw to add C++ version check & pkg-check for Qt5 :-) Regards, mpsuzuki On 2023/07/13 11:30, Hin-Tak Leung wrote: > Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both > to revise my makefile-fu, and perhaps as an educational tool for one of the > gsoc people struggling with makefiles. > > Here is a bare-minimum sketetal makefile for building ftinspect. It is > written to be minimal, it builds, and the resulting binary seems to work, but > since I have never used ftinspect, I don't know if the result does or does > not work correctly. > > Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a > few variables towards the top, edit them yourself), it should just build > ftinspect. There is a "make -f ftinpect.mk clean" target to clean up too. > > The fragment is written with the idea that it can be eventually loadable by > another. Current ft2-demo already do such for "./graph/rules.mk". > > - ideally it should be "include"d somewhere in the middle of the main > Makefile, like graph/rules.mk, and inherit the values of some of the > variables (*CFLAGS). > - adjusting paths (adds in some $(OBJ_DIR2)) and libtool adaptation (change > the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions). > - remove the "clean" target and merge its work with the main one. > > I'd be interested to know if the build binary is broken, or seems to do the > job, either way. > > Have fun adapting it... > > > > > On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster > wrote: > > > I've been preparing an update to the Debian package of FreeType and > realised ftinspect is limited to the meson build system only. Debian, > by default, has always used autotools. > > There are three build systems currently available for use in FreeType: > autotools, cmake and meson. As I understand past discussions, > autotools is the default (and fully supported). > > If ftinspect and, potentially, other software is not going to be built > via autotools, is there a case to move to another build system? > > Hugh
Re: [MPEG-OTSPEC] the actual skia based ft2-demo ot-svg renderer hook code diff (Re: Success - Re: Skia-based ot-svg renderer hook to freetype)
(removing OTSPEC list off CC') Toshiya Kun, Most of us simply ignore e-mails we aren't interested in reading... so as long as the subject title reflect the content and people have a choice of NOT opening the e-mail, I see no problem of posting about matter of limited interests. Fonts itself is already a topic not interesting to most people. I certainly don't read every e-mail arriving immediately, some of them not for a few days, some perhaps after a month or two, some left unopened for a long time. As for the actual subject matter. I think it is highly queationable that Google put more and earlier effort on suporting "not yet a spec" than "been a spec for 4 years". The primary failure is the idea that everything runs inside a web browser... A lot are, but not everything. Google folks can predict OT-SVG will be obsolete, BECAUSE Google chrome does not support it. :-). Maybe putting skia underneath FreeType and support ANG application will means that OT-SVG has a better future. That, I think is a matter of discussion on OTSPEC - the long term future of OT-SVG. Anyway, I fully expect people to stop reading at some point, and they should :-). Regards, Hin-Tak On Thursday, 13 July 2023 at 02:21:39 BST, suzuki toshiya wrote: Dear Hin-Tak, As one of the contributors of the FreeType and a person who had once struggled with Skia, I'm very happy to hear your progress report about the Skia-based backend of OT-SVG for FreeType. But I'm slightly questionable whether the subscribers of MPEG-OTSPEC are enjoying samely. Maybe some people in MPEG-OTSPEC have an interest in "How many open implementations for OT-SVG are working?", "What kind of new features in OT-SVG are expected?" or "When the support of OT-SVG would be enabled by default, or would it be easily configurable?". For such people, your posting would be very useful. But the people interested in the detailed comparison between the rsvg-backend and skia- backend might not be the majority of the subscribers of MPEG-OTSPEC. I apologize for saying such an inflexible thing, but, please reconsider the cross-posting (between the FreeType developers list and the MPEG-OTSPEC list) for highly- professional and deep implementation-dependent discussion specific to FreeType. Regards, mpsuzuki On 2023/07/13 4:43, Hin-Tak Leung wrote: > > Here it is, the actuall code diff for adding skia as a ot-svg renderer hook > to freetype, as an alternative to rsvg/cairo. There is a new file > "README.skia". I fixed the color change and the intermittent crash, so as far > as I know the only thing is that it is occasionally 1-pixel off compared to > rsvg/cairo. > > This can be somewhat corrected by changing these two lines: > > x = bounds.left(); -> floor(bounds.left()); > y = bounds.top(); -> floor(boulds.left()); > > I am not convinced that skia is entirey wrong, actually; the equivalent rsvg > location has some comments on doubts about rounding. > > I thought of switching the hooks dynamically (between 3, rsvg_hook, > skia_hook, and a new null_hook), but running init of one hook , switch in the > middle and run the free of another hook is dangerous. So this is still done > as a build-time change. Otherwise it would be great to switch dynamically to > investigate the 1-pixel-difference problem. > > For now, if somebody else wants to give this a try, especially a mac user or > a windows user, and/or somebody want to build skia (I am lazy and just > downloaded a not-too-old pre-built binaries), I like to hear about 1st-hand > experience on that too. > > The rest, please have a thought how to switch the hook dynamically, without > crashing > > will probably post this up at > https://github.com/HinTak/harfbuzz-python-demos/ under a new directory > "skia-adventure" and write there. Thanks for reading this far :-). > > > > > > > > > > On Wednesday, 12 July 2023 at 07:28:15 BST, Hin-Tak Leung > wrote: > > > See attached screenshot. Left is skia-based ftview/ftgrid, right is my > system-wide ftview/ftgrid 2.13.0 (based on rsvg/cairo). The default zoom > level for ftgrid seems to have changed between 2.13.0 and 2.13.1 from 4 to 6? > > There are 3 issues I see > > - the first one is of course the color - seems to be a rgba vs bgra > difference? i.e. the Alpha channel is the same, but red and blue swapped. > - 2nd one is not very noticeable on ftview but more on ftgrid - the glyph is > shifted down by one pixel. Probably a rounding error somewhere. > - I have intermitent crashes from 'include/core/SkRefCnt.h:72: fatal error: > "assert(this->getRefCnt() > 0)" ' . Prove I don't know Skia well enough yet. > ( That's one week of learning
skeletal makefile for ftinspect (Re: Future of autotools)
Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both to revise my makefile-fu, and perhaps as an educational tool for one of the gsoc people struggling with makefiles. Here is a bare-minimum sketetal makefile for building ftinspect. It is written to be minimal, it builds, and the resulting binary seems to work, but since I have never used ftinspect, I don't know if the result does or does not work correctly. Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a few variables towards the top, edit them yourself), it should just build ftinspect. There is a "make -f ftinpect.mk clean" target to clean up too. The fragment is written with the idea that it can be eventually loadable by another. Current ft2-demo already do such for "./graph/rules.mk". - ideally it should be "include"d somewhere in the middle of the main Makefile, like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS). - adjusting paths (adds in some $(OBJ_DIR2)) and libtool adaptation (change the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions). - remove the "clean" target and merge its work with the main one. I'd be interested to know if the build binary is broken, or seems to do the job, either way. Have fun adapting it... On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster wrote: I've been preparing an update to the Debian package of FreeType and realised ftinspect is limited to the meson build system only. Debian, by default, has always used autotools. There are three build systems currently available for use in FreeType: autotools, cmake and meson. As I understand past discussions, autotools is the default (and fully supported). If ftinspect and, potentially, other software is not going to be built via autotools, is there a case to move to another build system? Hugh ftinspect.mk Description: application/wine-extension-mk
the actual skia based ft2-demo ot-svg renderer hook code diff (Re: Success - Re: Skia-based ot-svg renderer hook to freetype)
Here it is, the actuall code diff for adding skia as a ot-svg renderer hook to
freetype, as an alternative to rsvg/cairo. There is a new file "README.skia". I
fixed the color change and the intermittent crash, so as far as I know the only
thing is that it is occasionally 1-pixel off compared to rsvg/cairo.
This can be somewhat corrected by changing these two lines:
x = bounds.left(); -> floor(bounds.left());
y = bounds.top(); -> floor(boulds.left());
I am not convinced that skia is entirey wrong, actually; the equivalent rsvg
location has some comments on doubts about rounding.
I thought of switching the hooks dynamically (between 3, rsvg_hook, skia_hook,
and a new null_hook), but running init of one hook , switch in the middle and
run the free of another hook is dangerous. So this is still done as a
build-time change. Otherwise it would be great to switch dynamically to
investigate the 1-pixel-difference problem.
For now, if somebody else wants to give this a try, especially a mac user or a
windows user, and/or somebody want to build skia (I am lazy and just downloaded
a not-too-old pre-built binaries), I like to hear about 1st-hand experience on
that too.
The rest, please have a thought how to switch the hook dynamically, without
crashing
will probably post this up at
https://github.com/HinTak/harfbuzz-python-demos/ under a new directory
"skia-adventure" and write there. Thanks for reading this far :-).
On Wednesday, 12 July 2023 at 07:28:15 BST, Hin-Tak Leung
wrote:
See attached screenshot. Left is skia-based ftview/ftgrid, right is my
system-wide ftview/ftgrid 2.13.0 (based on rsvg/cairo). The default zoom level
for ftgrid seems to have changed between 2.13.0 and 2.13.1 from 4 to 6?
There are 3 issues I see
- the first one is of course the color - seems to be a rgba vs bgra difference?
i.e. the Alpha channel is the same, but red and blue swapped.
- 2nd one is not very noticeable on ftview but more on ftgrid - the glyph is
shifted down by one pixel. Probably a rounding error somewhere.
- I have intermitent crashes from 'include/core/SkRefCnt.h:72: fatal error:
"assert(this->getRefCnt() > 0)" ' . Prove I don't know Skia well enough yet. (
That's one week of learning Skia ...)
On the way also learns a few things - this is based on m110 . I see that even
with main (close to m116), one of the headers I am using have changed location.
I tried updating skia-python 's bundled skia from m87 to m88 - just 1
milestone, or roughly 4 weeks, to get a feel of how easy/hard it is. The main
reason is that m88 is the first where the SVGDOM class is declared
non-experimental. So I expect the SVG related headers to move. But the actual
diff is close to about 1000 lines, took me a whole day. (by comparison, the
fontval diff is a little over 4000 lines, and took 3 years). The amount of
changes in skia per milestone is just alarming. That explains why nobody wants
to ship skia shared libraries, and why skia-python is stuck at m87 for 2 years.
Skia is just contantly changing from milestone to milstone.
That said, I think somebody should update skia-python's bundled skia from m87
to m98 (COLRv1) and perhaps even m103 (OT-SVG). Google folks?
One milestone is about 1000 lines of code difference and a whole day, I reckon
it will take somebody working full time for 2 months to update skia-python to
current-ish. (116 - 87 = 29 working days..., by the time one gets to m116,
m117/m118 would be out...). If google folks are not moving a finger, and
somebody else wants to fund me to tackle this, please feel free to get in touch.
I'll tidy the diff up and send it to freetype-devel at some point. At the
moment it is just replacing all contents of rsvg-port.{c,h}. with
-#ifdef HAVE_LIBRSVG
+#ifdef HAVE_SKIA
...
- SVG_RendererHooks rsvg_hooks = { NULL, NULL, NULL, NULL };
+ SVG_RendererHooks skia_hooks = { NULL, NULL, NULL, NULL };
...
(void)FT_Property_Set( handle->library,
- "ot-svg", "svg-hooks", _hooks );
+ "ot-svg", "svg-hooks", _hooks );
...
So potentionally I can add a toggle key to dynamically switch between
rsvg/cairo to skia rendering by just swapping _hooks with _hooks on
the fly.diff --git a/Makefile b/Makefile
index cded506..019e04d 100644
--- a/Makefile
+++ b/Makefile
@@ -61,6 +61,9 @@ ifeq ($(wildcard $(CONFIG_MK)),)
no_config_mk := 1
endif
+# Skia definitely want c++, and clang++ does not like -std=99
+# Why does this line has no effect?
+CC=g++
ifdef no_config_mk
exes:
@@ -136,8 +139,8 @@ else
#
# For the pure `make` call (without using `configure`) we have to add
# all needed cflags manually.
-FT_DEMO_CFLAGS := $(shell pkg-config --cflags librsvg-2.0) \
- -DHAVE_LIBRSVG
+FT_DEMO_CFLAGS := -I$(TOP_DIR_2)/skia/ \
+
Re: ftbench update: make integrated
(Please keep the CC to freetype-devel) libtool is also heavily in the GNU family, although mainly maintained by the people at https://sourceware.org/ , I think. (ancient time people politics...) . http://www.gnu.org/software/libtool/ is also quite well-maintained. You actually don't need to know much about libtool, really; it mostly just launches other commands. i.e. what follows " libtool —mode=compile " is mostly a valid compiler command, you should be able to cut and paste it and run it directly. If it does not work, variable expansions inside your makefile is wrong. So what follows --mode=compile should mostly looks like gcc source1.c -o source1.o or something similar. The "libtool —mode=link " mode is mostly a linker command too. So it should looks like gcc -Llocation1 -Llocation2 -lone -ltwo -Iinclude1 -Iinclude2 1source1.o source2.o source3.o -o binary1 The only difference from a properly valid linking command vs what follows "libtool —mode=link " is that some *.la files happens instead of the equivalent *.so or *.a . For example, I am doing ft2-demo builds at the moment, and the screen echos this commands it is running: libtool --mode=link ... /home/Hin-Tak/git-others/freetype2/objs/libfreetype.la ... in the middle. and it is followed by this information in the next line: libtool: link: ... /home/Hin-Tak/git-others/freetype2/objs/.libs/libfreetype.so ... What follows "libtool: link: " is the actual compiler command it is running. That you should be able to cut and paste and run directly and it should execute without error. Anyway, this is just a quick tutorial... there is no substitute for actually reading the manual :-). They are quite well written, as I keep saying :-). Your "libtool --mode=link " line below is obviously wrong. It is missing the actual compiler name (gcc/cc/clang) itself. On Wednesday, 12 July 2023 at 16:22:04 BST, Ahmet Göksu wrote: thanks a lot, Make works good actually :) the problem i am facing is linking the .o file to binary (even by terminal commands, manually). like: libtool —mode=link ftbench.o -o ftbench some binary, flag or parameter needed i think. Thanks, Goksu goksu.in On 12 Jul 2023 6:12 PM +0300, Hin-Tak Leung , wrote: The GNU Make manual is quite useful - and very well-written too. Go and download it and sit down for an afternoon, away from the keyboard, read sections of it. Good indexes and cross-references too. I think you probably want to do "make -n", for make to just print out what it will do, and just read what all the variables expanding to. It is really just Goal : dependencies How-to-make-goal-from-dependencies There is a section on implicit variables ($@, $^, $<, $CC) and patterns and substitutions, (usage of subst). As I said, it is very well written, and explains a lot of things much better than I or anybody could ever do in a short e-mail :-). On Wednesday, 12 July 2023 at 22:58:47 GMT+8, Ahmet Göksu wrote: actually i am stucked in linking. cc generates object file well but here i am missing something: $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) tried also this $(LIBTOOL) --mode=link $(CC) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) and this $(LIBTOOL) --mode=link $(CC) $^ -o $@ Best, Goksu goksu.in On 12 Jul 2023 5:33 PM +0300, Hin-Tak Leung , wrote: On Wednesday, 12 July 2023 at 21:25:05 GMT+8, Ahmet Göksu wrote: > but i am stucked to binary. $(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) > i am trying to do it same way in the demos, yet didnt figured it out. I haven't been following your work at all, so I could be wrong. I think you want to modify the first of the above line to: $(OBJ_DIR)/$(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) ... And elsewhere in the makefile, there should be a pseudo-target of the form: all : binary1 binary2 binary3 binary4 (in multiple lines continued and separated by "\") You want to change that to this sort of pattern too: all : $(OBJ_DIR)/binary1 ...
Re: ftbench update: make integrated
The GNU Make manual is quite useful - and very well-written too. Go and download it and sit down for an afternoon, away from the keyboard, read sections of it. Good indexes and cross-references too. I think you probably want to do "make -n", for make to just print out what it will do, and just read what all the variables expanding to. It is really just Goal : dependencies How-to-make-goal-from-dependencies There is a section on implicit variables ($@, $^, $<, $CC) and patterns and substitutions, (usage of subst). As I said, it is very well written, and explains a lot of things much better than I or anybody could ever do in a short e-mail :-). On Wednesday, 12 July 2023 at 22:58:47 GMT+8, Ahmet Göksu wrote: actually i am stucked in linking. cc generates object file well but here i am missing something: $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) tried also this $(LIBTOOL) --mode=link $(CC) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) and this $(LIBTOOL) --mode=link $(CC) $^ -o $@ Best,Goksugoksu.inOn 12 Jul 2023 5:33 PM +0300, Hin-Tak Leung , wrote: On Wednesday, 12 July 2023 at 21:25:05 GMT+8, Ahmet Göksu wrote: > but i am stucked to binary. $(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) > i am trying to do it same way in the demos, yet didnt figured it out. I haven't been following your work at all, so I could be wrong. I think you want to modify the first of the above line to: $(OBJ_DIR)/$(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) ... And elsewhere in the makefile, there should be a pseudo-target of the form: all : binary1 binary2 binary3 binary4 (in multiple lines continued and separated by "\") You want to change that to this sort of pattern too: all : $(OBJ_DIR)/binary1 ...
Re: ftbench update: make integrated
On Wednesday, 12 July 2023 at 21:25:05 GMT+8, Ahmet Göksu wrote: > but i am stucked to binary. $(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) $(LIBTOOL) --mode=link $(CC) $(subst /,$(f),$(LDFLAGS)) $^ -o $@ $(subst /,$(f),$(FTLIB) $(EFENCE)) > i am trying to do it same way in the demos, yet didnt figured it out. I haven't been following your work at all, so I could be wrong. I think you want to modify the first of the above line to: $(OBJ_DIR)/$(FTBENCH_BIN): $(OBJ_DIR)/ftbench.$(SO) ... And elsewhere in the makefile, there should be a pseudo-target of the form: all : binary1 binary2 binary3 binary4 (in multiple lines continued and separated by "\") You want to change that to this sort of pattern too: all : $(OBJ_DIR)/binary1 ...
Re: Future of autotools
On Tuesday, 11 July 2023 at 17:27:02 GMT+8, suzuki toshiya wrote: > If somebody wants to try to make autotools to support the building > of Qt5-based ftinspect, new configure should be added to freetype-demos, > to check the availability of the extra libraries for ftinspect? > Or, such check should be added to existing freetype/configure, even > if libfreetype itself has no dependency with them? This is definitely a "me too" moment. Am in the middle of ripping out the librsvg code and replacing it with skia in ftview/ftgrid, and rather annoyed that librsvg is detected in freetype2's configure rather than freetype2-demo's own. Freetype2 itself definitely has no dependency on librsvg and cairo!
Re: Future of autotools
On Monday, 10 July 2023 at 20:05:58 GMT+8, Hugh McMaster wrote: > I've been preparing an update to the Debian package of FreeType and > realised ftinspect is limited to the meson build system only. Debian, > by default, has always used autotools. > There are three build systems currently available for use in FreeType: > autotools, cmake and meson. As I understand past discussions, > autotools is the default (and fully supported). > If ftinspect and, potentially, other software is not going to be built > via autotools, is there a case to move to another build system? That's a bit unsatisfactory. Personally I only use the autotools/make to build. Also as far as I know, last I heard there is(was?) a bug of ttdebug being mis-built by meson - it is missing a -DUNIX or something of that sort to control the command buffering. I sort of feel like raising it from time to time when the GSoC students are updating the build system "have a look at fixing that too..." but ultimately it sounds like dumping uninteresting/tedious work on young people. I think Werner would respond at some point writing "patches welcome" for building ftinspect with autotools :-).
Re: 3 patches for freetype2 / freetype2-demo, and etc
On Sunday, 9 July 2023 at 05:17:55 BST, Werner LEMBERG wrote: > >> Hmm, what exactly do you suggest? `FT_LibraryRec` is an internal > >> structure not exposed to the public, so it could be changed easily > >> without any backward compatibility issues. > > > > Exactly as what I wrote - if a next major version of freetype (3) > > happens, and one is allowed to break backward compatibility. > Perhaps a misunderstanding: I want to know how *the code* should be > changed. Can you provide a pseudo-patch or something like that? I just means something like this - it being before "modules[FT_MAX_MODULES]" (a structure changeable in size per build/release) in particular. diff --git a/include/freetype/internal/ftobjs.h b/include/freetype/internal/ftobjs.h index 9f33d9c30..c768ce892 100644 --- a/include/freetype/internal/ftobjs.h +++ b/include/freetype/internal/ftobjs.h @@ -904,6 +904,7 @@ FT_BEGIN_HEADER FT_Int version_minor; FT_Int version_patch; + FT_DebugHook_Func debug_hooks[4]; FT_UInt num_modules; FT_Module modules[FT_MAX_MODULES]; /* module objects */ @@ -911,7 +912,6 @@ FT_BEGIN_HEADER FT_Renderer cur_renderer; /* current outline renderer */ FT_Module auto_hinter; - FT_DebugHook_Func debug_hooks[4]; #ifdef FT_CONFIG_OPTION_SUBPIXEL_RENDERING FT_LcdFiveTapFilter lcd_weights; /* filter weights, if any */
Re: Any prebuilt binary of Skia is widely distributed? (Re: Skia-based ot-svg renderer hook to freetype (Re: Scheduling Zoom meeting to discuss new...
Hiya - found a gem: https://github.com/JetBrains/skia-pack/releases They have m110 - lightly patched (they seems to have 16 patches on top, mostly making font rasterization settings changeable on-the-fly, I think). Static libraries plus headers. Seems to be for the purpose of using Skia with Java. Now bolting ft2-demo on top of skia (instead of rsvg) for rendering OT-SVG is do-able :-). On Thursday, 6 July 2023 at 13:48:52 GMT+8, suzuki toshiya wrote: Hi Hin-Tak, Are there any stable distributions of the prebuilt Skia binary, especially for Linux? The skia-python package has its own Skia binary (plus libbz2, libfreetype, libfontconfig, libpng, and libuuid). Once, I was involved in developing SVG Native Viewer, which has the backend to Skia. Checking the availability and compatibility of the Skia was a difficult problem. To test the features, I had to build the Skia binary by myself for testing, and it was too hard to incorporate into the CI testing because I don't believe in the reliability of a huge homegrown binary, and building the Skia binary consumes so long time for the CI platforms. In addition, even if there is an individual Skia package in some Linux distributions, maybe the Chromium browser would not use it - Chromium binary may merge the Skia into its binary, and there is no separate library. The skin-python can wrap up such issues, but I wonder whether the API of the prebuilt Skia binary in the PIP package is stable. And even if it is stable, I'm still wondering whether it is a good idea to link the binary content of the PIP package from the external (non-PIP) binaries. Are there any applications providing the Skia library as an individual component? Regards, mpsuzuki
Re: 3 patches for freetype2 / freetype2-demo, and etc
On Saturday, 8 July 2023 at 12:12:17 GMT+8, Werner LEMBERG wrote: > > One thing I'd like to suggest, if FreeType 3 is ever happening, is >.> for the DebugHook to move a bit earlier in the Library struct, and > > especially before any of the variable/adjustable sized > > sub-structures. It makes implementing interactive font debuggers / > > font editors with FreeType 3, and things like Fontval, in a non-C > > language, a bit easier. > Hmm, what exactly do you suggest? `FT_LibraryRec` is an internal > structure not exposed to the public, so it could be changed easily > without any backward compatibility issues. Exactly as what I wrote - if a next major version of freetype (3) happens, and one is allowed to break backward compatibility. FT_Library is a pointer to a FT_LibraryRec struct. golang and perl modules consumes C headers directly, so can find and set pointers some bytes away from the begging of a structure pointer. Python and C# modules gets at freetype's internal structures by maintaining a duplicate non-C description of these structures. So getting/setting members of structures some distance away from the beginning (and somewhat variable distances too) is quite hard. I know font debugger / editor is probably a rare usage of freetype, so rarely used members of structures should go to the end (and also probably union'ed for repurposing the same bits of memory). Maybe if they are easier to access, it might encourage their usage.
Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype
On Saturday, 8 July 2023 at 12:36:45 GMT+8, Werner LEMBERG wrote: > > If the Freetype folks want to port to freetype2-demos, and add the > > missing renderNode() to support all OT-SVG (I mean Google OT-SVG > > fonts...) with a different svg rendering engine than rsvg, they can > > fish it out of freetype-py/examples ... :-). > Well, I don't think *we* want to port this. Contributions, however, > are always welcomed :-) I wrote that initially for a bit of giggle - FreeType using a massive beast like skia merely to hand out a svg glyph and receive color bitmap back. But it isn't as crazy as it sounds. Checked that librsvg is just under 5MB on my system, freetype just under 1MB, cairo* comes to about 2MB. The pip installed skia-python skia m87 shared library is 25MB. (But it has a lot of stuff built-into it). So if I take out all the bundled libraries and make a skia.so which re-uses system libraries, it might come down to about 10MB, closer to librsvg + cairo. And since m103 is necessary for OT-SVG, 5 months later than m98 for COLRv1 (Google milestones are 4 weeks apart, apparently). So trying to hook skia m103+ up underneath FreeType would probably go towards bring COLRv1 support too. Kind of surprised that skia-python's bundled skia is so old/outdated - considering skia is google technology, and how *cough* fanatical *cough* google folks are with everything python. :-).
Re: How to use "autofitter" with TTF
On Saturday, 8 July 2023 at 19:35:09 GMT+8, Devesh Sharma (M20AIE233) wrote: > I reviewed the pygame source and it seems their "freetype" interface is > missing harfbuzz objects internally, thus, when pygame-freetype passes > requests to FT, the FT-Face do not have valid hb_* object pointers. I am > thinking of making a change in pygame interface. Do you think it will fly and > doable? If you are using Devanagari fonts you have to get harfbuzz involved at some stage, either directly or indirectly. There are nicer (python) libraries to use like uharbuzz (just search for "harfbuzz python" on github or Google...). That said, another shameless plug: https://github.com/HinTak/harfbuzz-python-demos The code is a combination of quite low-level freetype and harfbuzz calls - basically get harfbuzz to convert from character strings to list of glyphs plus positioning offsets, then use freetype to get at the bitmaps, then draw the bitmaps at the positions and offsets from harfbuzz. It is not how most people who use Indic language to do it (most prefer some higher level libraries) - I wrote it mostly to learn about harfbuzz , reusing some of the python code I contributed to freetype-py. By the way, you can ask freetype-py directly what version of freetype it is using. In your case, something like: import pygame.freetype print(pygame.freetype.version()) would do it. I just try that on my system (with "import freetype; print(freetype.version())", using the system copy of freetype-py rather than pygame's). It prints (2,13,0) which is the expected answer. (2.13.1 was out two weeks ago and I haven’t upgraded yet).
Re: Skia-based ot-svg renderer hook to freetype
I think I have finished this venture for now. Just pushed a "ot-svg-draw-skia.py" to freetype-py/examples. The top of the file has block of comments: Limitation: Skia-python bundles with Skia m87 (at time of writing this). Skia m88 is first version where SkSVG* is considered no longer experimental. Skia m103 is the first Skia build which contains 9cbadcd9280dc139af2f4d41d25a6c9a750e0302. That introduces "SkSVGDOM::renderNode()" among other stuff, necessary for rendering "some" OT-SVG fonts. Guess what, that commit is titled "Add optional OT-SVG support to FreeType"! So the example below only works correctly for "some" glyphs in "some other" OT-SVG fonts, and also with very limited functionality beyond what is used below. The missing functionality (and support for beyond Skia m103) is filed as skia-python issue #192. And with that, I'd also make three more comments: - m98 is when Google Chrome introduced COLRv1 support (The first entry searching for "COLRv1 renderer" on my android phone is a blog post about "COLRv1 in Chrome 98"...). i.e. Google supports COLRv1 (not yet part of OFF) earlier than OT-SVG (was in OFF 4th in 2019) with m103. That commit is dated April 2022. - 9cbadcd9280dc139af2f4d41d25a6c9a750e0302 itself contains most of what a "Skia-based ot-svg renderer hook to freetype" would look like, plus everything it depends on. If anybody wants to bolt Skia underneath freetype to enable any application which uses FreeType to use OT-SVG fonts (like adapting ft2-demos to use skia instead of rsvg...), reading that commit is both necessary and sufficient :-), I think. - the missing "SkSVGDOM::renderNode()" also distinguishes Adobe/Mozilla-origin OT-SVG fonts vs Google-origin OT-SVG fonts. Again this difference reflects how they are made. A higher proportion of glyphs in Adobe/Mozilla-origin OT-SVG are singe-glyph SVG documents, vs multiple-glyph layered SVG documents. Google's way of making OT-SVG fonts is more size-conscious and uses multiple-glyph layer SVG documents more often (for obvious reasons of webfont usage...). This is a per-glyph issue, so I am saying that a higher proportion of glyphs in Adobe/Mozilla-origin OT-SVG fonts works without the missing "SkSVGDOM::renderNode()", than in Google-origin OT-SVG fonts.
Re: 3 patches for freetype2 / freetype2-demo, and etc
Argh, sorry, small mistake in the one for freetype2 . Here is the correct version. I am sure you know why/how the mistake happened :-), if you try to apply the older one in that 3. On Friday, 7 July 2023 at 20:34:38 BST, Hin-Tak Leung wrote: Hi Werner, 3 patches, one for freetype2, and two for freetype2-demos (the rsvg one is a re-post). None of them are anything critical. I think I'd really like the rsvg one to go in, if only to stay sync with the corresponding python code in freetype-py/examples. I am also very sure you do not want it to go in as currently is; you most likely want to code the same idea in a different way - but it is a start. The freetype2 one is a discovery from rebasing the Fontval diff. The 3rd one in ft2-demos is sort of in the same area, and recent thoughts on RendererHook's and DebugHook's signatures. One thing I'd like to suggest, if FreeType 3 is ever happening, is for the DebugHook to move a bit earlier in the Library struct, and especially before any of the variable/adjustable sized sub-structures. It makes implementing interactive font debuggers / font editors with FreeType 3, and things like Fontval, in a non-C language, a bit easier. Yes, I briefly thought of expanding freetype-py, and re-writing ttdebug in python. It cannot happen (easily... alway a matter of how much pain/trouble one wants to bear...) for the reason above :-). And same with FontVal-RX - the next stage of FontVal, with dual freetype and microsoft backends. Hin-Tak From 2687e0378f8798b0cc262362ed5f942e3e693961 Mon Sep 17 00:00:00 2001 From: Hin-Tak Leung Date: Fri, 7 Jul 2023 19:24:48 +0100 Subject: [PATCH] * src/truetype/ttgload.c (TT_Hint_Glyph): More mostly cosmetic update. This is a follow-up to 49c74ac021f8139e83bbd65df75217d0de284eea, which creates a new local variable "exec = loader->exec", and shortening a lot of "loader->exec". This commit does two more such changes missed in that first commit. Signed-off-by: Hin-Tak Leung --- src/truetype/ttgload.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/truetype/ttgload.c b/src/truetype/ttgload.c index 5f15a7f4d..d538e8ee8 100644 --- a/src/truetype/ttgload.c +++ b/src/truetype/ttgload.c @@ -820,7 +820,7 @@ FT_ARRAY_COPY( zone->org, zone->cur, zone->n_points ); /* Reset graphics state. */ -loader->exec->GS = loader->size->GS; +exec->GS = loader->size->GS; /* XXX: UNDOCUMENTED! Hinting instructions of a composite glyph */ /* completely refer to the (already) hinted subglyphs. */ @@ -860,7 +860,7 @@ exec->is_composite = is_composite; exec->pts = *zone; - error = TT_Run_Context( loader->exec ); + error = TT_Run_Context( exec ); if ( error && exec->pedantic_hinting ) return error; -- 2.41.0
3 patches for freetype2 / freetype2-demo, and etc
Hi Werner,
3 patches, one for freetype2, and two for freetype2-demos (the rsvg one is a
re-post).
None of them are anything critical. I think I'd really like the rsvg one to go
in, if only to stay sync with the corresponding python code in
freetype-py/examples. I am also very sure you do not want it to go in as
currently is; you most likely want to code the same idea in a different way -
but it is a start.
The freetype2 one is a discovery from rebasing the Fontval diff. The 3rd one in
ft2-demos is sort of in the same area, and recent thoughts on RendererHook's
and DebugHook's signatures.
One thing I'd like to suggest, if FreeType 3 is ever happening, is for the
DebugHook to move a bit earlier in the Library struct, and especially before
any of the variable/adjustable sized sub-structures. It makes implementing
interactive font debuggers / font editors with FreeType 3, and things like
Fontval, in a non-C language, a bit easier.
Yes, I briefly thought of expanding freetype-py, and re-writing ttdebug in
python. It cannot happen (easily... alway a matter of how much pain/trouble one
wants to bear...) for the reason above :-). And same with FontVal-RX - the next
stage of FontVal, with dual freetype and microsoft backends.
Hin-Tak
From 1aecf30b9ff9ef75a7a3cb1957a0c452ac92da74 Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Fri, 7 Jul 2023 19:24:48 +0100
Subject: [PATCH] * src/truetype/ttgload.c (TT_Hint_Glyph): More mostly
cosmetic update.
This is a follow-up to 49c74ac021f8139e83bbd65df75217d0de284eea,
which creates a new local variable "exec = loader->exec", and
shortening a lot of "loader->exec". This commit does two more
such changes missed in that first commit.
Signed-off-by: Hin-Tak Leung
---
src/truetype/ttgload.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/truetype/ttgload.c b/src/truetype/ttgload.c
index 238e9533d..430323926 100644
--- a/src/truetype/ttgload.c
+++ b/src/truetype/ttgload.c
@@ -820,7 +820,7 @@
FT_ARRAY_COPY( zone->org, zone->cur, zone->n_points );
/* Reset graphics state. */
-loader->exec->GS = loader->size->GS;
+exec->GS = loader->size->GS;
/* XXX: UNDOCUMENTED! Hinting instructions of a composite glyph */
/* completely refer to the (already) hinted subglyphs. */
@@ -863,7 +863,7 @@
#ifdef FT_DIAGNOSTICS
loader->exec->nested_IF_level = 0;
#endif
- error = TT_Run_Context( loader->exec );
+ error = TT_Run_Context( exec );
if ( error && exec->pedantic_hinting )
return error;
--
2.41.0
From f0e543f90a7350261d83a6a5a1dfadefd3533ad7 Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Fri, 7 Jul 2023 19:54:21 +0100
Subject: [PATCH] [ttdebug] Signature fixes.
A somewhat similar change to what happened in freetype2, in commit
95d635eab1b08a0051de07b6c33067d2c1984848.
commit 95d635eab1b08a0051de07b6c33067d2c1984848
Author: Werner Lemberg
Date: Sun May 7 08:34:32 2023 +0200
[truetype] Signature fixes.
Signed-off-by: Hin-Tak Leung
---
src/ttdebug.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/ttdebug.c b/src/ttdebug.c
index 188a213..37342be 100644
--- a/src/ttdebug.c
+++ b/src/ttdebug.c
@@ -1978,8 +1978,10 @@
static FT_Error
- RunIns( TT_ExecContext exc )
+ RunIns( void* exec )
{
+TT_ExecContext exc = (TT_ExecContext)exec;
+
FT_Int key;
FT_Bool really_leave;
@@ -3052,7 +3054,7 @@
FT_Set_Debug_Hook( library,
FT_DEBUG_HOOK_TRUETYPE,
- (FT_DebugHook_Func)RunIns );
+ RunIns );
printf( "%s\n"
"press key `h' or `?' for help\n"
--
2.41.0
From 216f39cec1fe8719762aad593568015bd01622cb Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Fri, 30 Jun 2023 02:45:38 +0100
Subject: [PATCH] * src/rsvg-port.c (rsvg_port_preset_slot): simplify usage of
rsvg_handle_render_*
* src/rsvg-port.c (rsvg_port_preset_slot): Remove usage of `rsvg_handle_render_document'
(and `rsvg_handle_render_cairo'). They are functionally the same as
`rsvg_handle_render_layer' (and `rsvg_handle_render_cairo_sub') with argument
id set to NULL.
Signed-off-by: Hin-Tak Leung
---
src/rsvg-port.c | 80 +
1 file changed, 27 insertions(+), 53 deletions(-)
diff --git a/src/rsvg-port.c b/src/rsvg-port.c
index 16faa14..5861e19 100644
--- a/src/rsvg-port.c
+++ b/src/rsvg-port.c
@@ -334,69 +334,43 @@
/* If the document contains only one glyph, `start_glyph_id` and */
/* `end_glyph_id` have the same value. Otherwise `end_glyph_id` */
/* is larger.*/
-if ( start_glyph_id == end_glyph_id )
-{
- /* Render the whole document to the recording surface. */
-#if LIBRSVG_CHECK_VERSION( 2, 52, 0 )
- {
-
Savannah ft2-demos repo no longer getting updated?
Hi, I set up both freetype2 and ft2-demos for multiple remotes and track both gnu savannah and gitlab in both. For most parts freetype2 to stay in sync (I think occasionally one stays behind the other for a day or two), but ft2-demos on savannah is a couple of months behind gitlab now. Is that intentional or oversight? I assume it is just oversight since freetype2 stays in sync more or less, and it is one of those things that only needs a one-off set up and works forever afterwards.
Re: Any prebuilt binary of Skia is widely distributed? (Re: Skia-based ot-svg renderer hook to freetype (Re: Scheduling Zoom meeting to discuss new proposals and AHG recommendations)
On Thursday, 6 July 2023 at 13:48:52 GMT+8, suzuki toshiya wrote: > Are there any stable distributions of the > prebuilt Skia binary, especially for Linux? > The skia-python package has its own Skia > binary (plus libbz2, libfreetype, libfontconfig, > libpng, and libuuid). Toshiya Kun, Not any I know of. You are right, skia-python pip install comes with its own skia binary, plus a few dependent library's. I also cloned skia-python and had a quick look (already filed my first pull fixing a small mis-written doc, and a missing feature issue - the guy says "pull welcomed", so I possibly will try to build skia-python from source at some point). It bundles skia m87 from 2021, and libfreetype 2.8 . Current skia is around m100 I think, as I remember reading about "COLRv1 in m98" :-). > In addition, even if there is an individual > Skia package in some Linux distributions, > maybe the Chromium browser would not use it > - Chromium binary may merge the Skia into > its binary, and there is no separate library. I just checked chromium - it is a 200MB+ binary, which presumably includes the ~25MB skia in skia-python. I think if anybody would try to modularize skia as a shared library it would be the chromium people. So it hasn't been done yet. > The skin-python can wrap up such issues, but > I wonder whether the API of the prebuilt Skia > binary in the PIP package is stable. And even > if it is stable, I'm still wondering whether > it is a good idea to link the binary content > of the PIP package from the external (non-PIP) > binaries. Are there any applications providing > the Skia library as an individual component? I think the first part of your question is yet. The bundled skia in skia-python has been stuck at m87 for a couple of years, and there are a few open issues filed at skia-python about updating it. As for the other two questions, I think the last one is no, there is no effort (visible) of any party providing skia as an individual component. As for the 2nd question - I think if the skia-python people are clued-up, they would hid all the skia symbols with linker tricks, and only expose the pybind11 python hooks - it is a performance itself to not show too many public symbols more than necessary - so it may not even be usable by non-PIP parties. (I am thinking probably the opposite of what you are suggesting, a non-python application re-using the prebuilt skia-python bundled skia, instead of what you are aiming at, that skia-python using an external skia, which is also shared with some non-python application) anyway, it looks like at the moment skia is alwaya bundled in something else. Regards,Hin-Tak P.S. zoom call on 20 minutes How exciting!
The Google OT-SVG "quirk" (Re: [MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype)
I think I am broadly in agreement with you. FWIW, I don't think this difference in Adobe/Mozilla-origin OT-SVG font versus Google-origin OT-SVG font is a bug in Google Fonts. That's why I never filed it as such. The difference as far as I guess, is as you described, though I'd put it in different words: the difference reflects how they were made. Adobe/Mozilla OT-SVG fonts were created natively on SVG-capable editors like Adobe Illustrators, etc then assembled as such, so have all the conventional SVG attributes expected of them from standalone SVG rendering libraries. Google-origin OT-SVG fonts are programmatically converted from font outlines in a different format, so have a more minimalistic nature, and also relies on some other information kept in the rest of the font structures, to be "complete" equivalent to standalone SVG graphics. As I also mentioned, Skia / skia-python's SVG parser returns 0,0 for width/height for SVG from Google-origin OT-SVG fonts. So it needs a "0,0 means EM,EM "hint"" to be rendered as standalone SVG too. Ie. Skia also distinguishes the two "types" of OT-SVG fonts as far as treating the SVG glyphs as SVG graphics goes. On Thursday, 6 July 2023 at 09:02:40 GMT+8, Rod Sheeter wrote: If I'm following correctly https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/626b43db566f907fa7b6926705e914259c54b9cf is working around a bug that results from rsvg taking an svg2 interpretation of width/height. That seems a bit odd as the opentype spec specifically references http://www.w3.org/TR/SVG11 and the svg documents in Google-origin ot-svg seem to explicitly indicate that they are in svg 1.1 () and thus probably shouldn't be interpreted using svg 2 conventions. For context, "Google-origin ot-svg" is likely built by https://github.com/googlefonts/nanoemoji. Based on a quick glance at some of our testdata, e.g. https://github.com/googlefonts/nanoemoji/blob/main/tests/rect_picosvg.ttx, it looks to me like we followed the examples given in https://learn.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers and do not include viewbox or width/height. We assume units to be interpreted as advised in https://learn.microsoft.com/en-us/typography/opentype/spec/svg#coordinate-systems-and-glyph-metrics. Cheers, Rod S. On Wed, Jul 5, 2023 at 4:10 PM Hin-Tak Leung wrote: Okay it says "out-of-memory condition" https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/626b43db566f907fa7b6926705e914259c54b9cf instead of "memory exhaustion" (I think that's my subject heading when I posted to freetype-devel). It has my name on it, and is the 3rd most recent commit on freetype2-demos (as of now). You didn't look. On Thursday, 6 July 2023 at 06:43:35 GMT+8, Hin-Tak Leung wrote: Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something like a few hundred, a few hundred. The bug fix in freetype2-demos I submitted was that, if it comes out as 1,1, it means EM, EM (1024, 2048 or there abouts). Search for "memory exhaustion" in the freetype2-demos commit log, as I suggested. It isn't that hard to find. On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung wrote: It is the result from the "intrinsic dimensions" routine - (there is a routine of that sort of name in both rsvg and skia). It returns some larger numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg and 0,0 from skia for Google-origin OT-SVG fonts. Clear enough? On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo wrote: I have no idea what you're talking about. Please, clarify what this difference is supposed to be, otherwise this is just spreading rumors. On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung wrote: On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ...&q
Re: Skia-based ot-svg renderer hook to freetype
Okay it says "out-of-memory condition" https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/626b43db566f907fa7b6926705e914259c54b9cf instead of "memory exhaustion" (I think that's my subject heading when I posted to freetype-devel). It has my name on it, and is the 3rd most recent commit on freetype2-demos (as of now). You didn't look. On Thursday, 6 July 2023 at 06:43:35 GMT+8, Hin-Tak Leung wrote: Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something like a few hundred, a few hundred. The bug fix in freetype2-demos I submitted was that, if it comes out as 1,1, it means EM, EM (1024, 2048 or there abouts). Search for "memory exhaustion" in the freetype2-demos commit log, as I suggested. It isn't that hard to find. On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung wrote: It is the result from the "intrinsic dimensions" routine - (there is a routine of that sort of name in both rsvg and skia). It returns some larger numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg and 0,0 from skia for Google-origin OT-SVG fonts. Clear enough? On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo wrote: I have no idea what you're talking about. Please, clarify what this difference is supposed to be, otherwise this is just spreading rumors. On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung wrote: On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ..." clause separating the two in Skia related code, if /when I finish.
Re: Skia-based ot-svg renderer hook to freetype
Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something like a few hundred, a few hundred. The bug fix in freetype2-demos I submitted was that, if it comes out as 1,1, it means EM, EM (1024, 2048 or there abouts). Search for "memory exhaustion" in the freetype2-demos commit log, as I suggested. It isn't that hard to find. On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung wrote: It is the result from the "intrinsic dimensions" routine - (there is a routine of that sort of name in both rsvg and skia). It returns some larger numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg and 0,0 from skia for Google-origin OT-SVG fonts. Clear enough? On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo wrote: I have no idea what you're talking about. Please, clarify what this difference is supposed to be, otherwise this is just spreading rumors. On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung wrote: On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ..." clause separating the two in Skia related code, if /when I finish.
Re: Skia-based ot-svg renderer hook to freetype
Actually Adobe/Mozilla OT-SVG fonts do *not* return EM, EM but something like a few hundred, a few hundred. The bug fix in freetype2-demos I submitted was that, if it comes out as 1,1, it means EM, EM (1024, 2048 or there abouts). Search for "memory exhaustion" in the freetype2-demos commit log, as I suggested. It isn't that hard to find. On Thursday, 6 July 2023 at 06:36:49 GMT+8, Hin-Tak Leung wrote: It is the result from the "intrinsic dimensions" routine - (there is a routine of that sort of name in both rsvg and skia). It returns some larger numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg and 0,0 from skia for Google-origin OT-SVG fonts. Clear enough? On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo wrote: I have no idea what you're talking about. Please, clarify what this difference is supposed to be, otherwise this is just spreading rumors. On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung wrote: On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ..." clause separating the two in Skia related code, if /when I finish.
Re: Skia-based ot-svg renderer hook to freetype
It is the result from the "intrinsic dimensions" routine - (there is a routine of that sort of name in both rsvg and skia). It returns some larger numbers, EM,EM I think for Adobe/Mozilla OT-SVG fonts, but 1,1 from rsvg and 0,0 from skia for Google-origin OT-SVG fonts. Clear enough? On Wednesday, 5 July 2023 at 22:00:54 GMT+8, Cosimo Lupo wrote: I have no idea what you're talking about. Please, clarify what this difference is supposed to be, otherwise this is just spreading rumors. On Wed, Jul 5, 2023 at 2:33 PM Hin-Tak Leung wrote: On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ..." clause separating the two in Skia related code, if /when I finish.
Re: Skia-based ot-svg renderer hook to freetype
On Wednesday, 5 July 2023 at 20:49:42 GMT+8, Hin-Tak Leung wrote: > On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla > sources, and the rest (more than 2 and less than 10) from Google Fonts. The > two sets behave differently, and get processed by two different code paths in > freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in > freetype2-demos about a month ago; the Adobe/Mozilla set does not. > That was all part of the activities around the time with the Google font SVG > subsetting bug. Look at the freetype2-demo log around the same time you > investigated and fixed the subletting bug. Actually having looked at Skia and skia-python's SVG related functionality last night, Skia also follows two slightly different code paths for the two "types" of OT-SVG fonts. There will be a small "if x else ..." clause separating the two in Skia related code, if /when I finish.
Re: Skia-based ot-svg renderer hook to freetype
On Wednesday, 5 July 2023 at 03:24:11 GMT+8, Cosimo Lupo 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 that many OT-SVG fonts - 3 from Adobe/Mozilla sources, and the rest (more than 2 and less than 10) from Google Fonts. The two sets behave differently, and get processed by two different code paths in freetype2-demos. The Google set triggers the memory exhaustion bug I fixed in freetype2-demos about a month ago; the Adobe/Mozilla set does not. That was all part of the activities around the time with the Google font SVG subsetting bug. Look at the freetype2-demo log around the same time you investigated and fixed the subletting bug.
Skia-based ot-svg renderer hook to freetype (Re: [MPEG-OTSPEC] Scheduling Zoom meeting to discuss new proposals and AHG recommendations)
(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 skia-python is missing the python equivalent of SKSVGDOM::renderNode() . This means that if I re-write the rsvg-based python svgrender hooks with skia-python, it would only work with Adobe/Mozilla OT-SVG fonts, but not Google OT-SVG fonts (until skia-python improves). I think I'll give it a go and try to put an example out under freetype-py/examples (probably will call it "ot-svg-example-skia.py", after the other "ot-svg-example.py") . If the Freetype folks want to port to freetype2-demos, and add the missing renderNode() to support all OT-SVG (I mean Google OT-SVG fonts...) with a different svg rendering engine than rsvg, they can fish it out of freetype-py/examples ... :-). On Tuesday, 4 July 2023 at 21:58:10 GMT+8, Hin-Tak Leung wrote: On Tuesday, 4 July 2023 at 21:30:56 GMT+8, Dominik Röttsches wrote: > ... I don't think it would be the right architectural choice to redundantly > repeat these concepts inside FreeType itself. Even more so, as fast > compositing and gradient implementations require time and effort to make > them reasonably fast. It isn't repeating these concepts in Freetype. Currently, in one (actually two, c and python) implementation, Freetype farms off rendering of OT-SVG glyphs to rsvg, which in turn is cairo-based, to do the actual rendering. FreeType just provides a plug-in system which allows an external library to do the rendering. Basically Freetype gives out the glyph svg outlines etc, and the external library fill in the extent and the actual buffer of a rendered bitmap. This allows any freetype-based applications to use OT-SVG fonts. ___ mpeg-otspec mailing list mpeg-ots...@lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec
Re: How to use "autofitter" with TTF
Not really a python guy myself either, but I know enough python & freetype to
be trusted with commit access to freetype-py (I think I wrote about half of
their bundled examples. A few years ago when I decided I wanted to learn
pycairo, I rewrote all their existing examples from PIL+numpy to pycairo... so
doubling the number) - that's the "x.freetype.x" part you are using below. So I
read some freetype-py issues filed too.
If I remember correctly, pygame bundles their own rather old freetype-py fork
in their "pygame.freetype." part, and possibly also a very old private
libfreetype too. So problems you experienced might just be because of using old
code (as in, freetype 2.5 era...).
You might want to check versions of both.
That path /usr/share/fonts/truetype/Sarai/Sarai.ttf looks linux - Debian or
Ubuntu? They ship some fonts of questionable quality...
Lastly, shameless plug: Font Validator is your friend...
I collects FontVal reports from all shipped fonts on fedora and ubuntu from
time to time, specifically just the rasterizer/ hinting instructions part as
FontVal's testing. I think the report for this font (just the hinting
instructions part) might be filed under
https://github.com/HinTak/FontVal-Tests-at-10pt/ already, under the Ubuntu or
the fedora branch.
On Friday, 30 June 2023 at 21:18:21 GMT+8, Werner LEMBERG
wrote:
> Thanks, but I'm not a Python guy, so I won't test this by myself.
> > font = pygame.freetype.Font("/usr/share/fonts/truetype/Sarai/Sarai.ttf", 50)
...
Another patch for ft2-demo (Re: ft2-demo ot-svg support ported to python freetype-py/pycairo)
Hi Werner,
Here is the patch. I think you might want to do some stylistic changes, but
let's start with something concrete. Strictly speaking the logic is a little
different from how it was, for the case of malformed svg documents where
"start_glyph_id > end_glyph_id" (normal is "=" and "<"). I think the new
behavior is better - malformed svg documents get rendered so you see something,
and hopefully something wildly wrong, thus letting you know that it is
malformed (in the old, malformed svg glyphs don't render).
Also currently the code does not check that glyph_index is between
start_glyph_id and end_glyph_id . Should it? This is the part where those
Google fonts a few weeks ago would have been flagged as faulty. Should a
"fprintf( stderr, ..." be where "start_glyph_id > end_glyph_id" and also if
glyph_index is outside start_glyph_id and end_glyph_id ?
I don't feel strongly either way, but removing 25 lines, and a large "if ...
then ..." makes it easier to read.
Hin-Tak
On Friday, 30 June 2023 at 01:43:51 BST, Hin-Tak Leung
wrote:
...
I think I'll prepare a patch for removing rsvg_handle_render_document(), but I
don't feel too strongly that way - it is functionally the same, just removing
about 20 lines and makes the file easier to read (in the future).
...From 216f39cec1fe8719762aad593568015bd01622cb Mon Sep 17 00:00:00 2001
From: Hin-Tak Leung
Date: Fri, 30 Jun 2023 02:45:38 +0100
Subject: [PATCH] * src/rsvg-port.c (rsvg_port_preset_slot): simplify usage of
rsvg_handle_render_*
* src/rsvg-port.c (rsvg_port_preset_slot): Remove usage of `rsvg_handle_render_document'
(and `rsvg_handle_render_cairo'). They are functionally the same as
`rsvg_handle_render_layer' (and `rsvg_handle_render_cairo_sub') with argument
id set to NULL.
Signed-off-by: Hin-Tak Leung
---
src/rsvg-port.c | 80 +
1 file changed, 27 insertions(+), 53 deletions(-)
diff --git a/src/rsvg-port.c b/src/rsvg-port.c
index 16faa14..5861e19 100644
--- a/src/rsvg-port.c
+++ b/src/rsvg-port.c
@@ -334,69 +334,43 @@
/* If the document contains only one glyph, `start_glyph_id` and */
/* `end_glyph_id` have the same value. Otherwise `end_glyph_id` */
/* is larger.*/
-if ( start_glyph_id == end_glyph_id )
-{
- /* Render the whole document to the recording surface. */
-#if LIBRSVG_CHECK_VERSION( 2, 52, 0 )
- {
-RsvgRectangle viewport =
-{
- .x = 0,
- .y = 0,
- .width = (double)dimension_svg.width,
- .height = (double)dimension_svg.height,
-};
-
-
-ret = rsvg_handle_render_document( handle,
- rec_cr,
- ,
- NULL );
- }
-#else
- ret = rsvg_handle_render_cairo( handle, rec_cr );
-#endif
-
- if ( ret == FALSE )
- {
-error = FT_Err_Invalid_SVG_Document;
-goto CleanCairo;
- }
-}
-else if ( start_glyph_id < end_glyph_id )
-{
- char str[32] = "#glyph";
+/* NULL = Render the whole document */
+char *id = NULL;
+char str[32] = "#glyph";
+if ( start_glyph_id < end_glyph_id )
+{
/* Render only the element with its ID equal to `glyph`. */
sprintf( str + 6, "%u", slot->glyph_index );
+ id = str;
+}
#if LIBRSVG_CHECK_VERSION( 2, 52, 0 )
+{
+ RsvgRectangle viewport =
{
-RsvgRectangle viewport =
-{
- .x = 0,
- .y = 0,
- .width = (double)dimension_svg.width,
- .height = (double)dimension_svg.height,
-};
-
-
-ret = rsvg_handle_render_layer( handle,
-rec_cr,
-str,
-,
-NULL );
- }
+.x = 0,
+.y = 0,
+.width = (double)dimension_svg.width,
+.height = (double)dimension_svg.height,
+ };
+
+
+ ret = rsvg_handle_render_layer( handle,
+ rec_cr,
+ id,
+ ,
+ NULL );
+}
#else
- ret = rsvg_handle_render_cairo_sub( handle, rec_cr, str );
+ret = rsvg_handle_render_cairo_sub( handle, rec_cr, id );
#endif
- if ( ret == FALSE )
- {
-error = FT_Err_Invalid_SVG_Document;
-goto CleanCairo;
- }
+if ( ret == FALSE )
+{
+ error = FT_Err_Invalid_SVG_Document;
+ goto CleanCairo;
}
/* Get the bounding box of the drawing. */
--
2.41.0
