June 2014 - Xquartz-dev - lists.macosforge.org

Fwd: infinality in/under MacPorts
by "René J.V. Bertin" 26 Jun '14

26 Jun '14

FYI. Begin forwarded message: > From: bohoomil <infinalityfonts@> > Date: June 24, 2014 22:54:14 CEST > To: René J.V. Bertin <rjvbertin@> > Subject: Re: infinality in/under MacPorts > > On 24.06.14 at 10:40, René J.V. Bertin wrote: > > Hi again, > > I'm glad that freetype2 was built successfully. Let me answer the questions now. > > >> On Tuesday June 24 2014, René J.V. Bertin wrote regarding "Re: infinality in/under MacPorts" >> >>> freetype-2.5.3-enable-valid.patch >>> upstream-15.05.2014.patch >>> infinality-2.5.3.patch >> >> Ok, that explains things - hopefully (:) ) Does one still get the offset corrections on the aflatin.c file as I got using only the infinality-2.5.3 patch? > > The offset is not a problem: it merely means that the patching application > found the code in a different location than expected. The context of the code to > be altered was correct, though: if it hadn't been, the patching would have been > interrupted. > >> Do you know of any legal obstacles that would explain why this has never been done by X.org? No (L)GPL-3 licensing on any of the patches, which would be a no-go for Apple? > > Not really. As per freetype2 home page, the patents related to bytecode > interpreter expired in May 2010. As a result, last year quite a few bits from > Infinality patchset were included in the official freetype2 code base. The rest > of the Infinality code extends configuration capabilities of the TrueType > interpreter. > > The author of Infinality patchset hasn't been active for almost a year now. I > merely maintain the patches and, as far as my knowledge allows, try to adapt > them to recent freetype2 releases. Besides, I develop > fontconfig-infinality-ultimate library as a companion to freetype2-iu, plus > alternative Infinality settings. The complete collection of software in binary > packages is available in the repository for Arch Linux users. Other > distributions can use it all the same: all they need to do is grab the code, > patch the stock libraries and use additional configuration files. > >> You mean 3 patches, right, or 3 packages? MacPorts doesn't usually split up projects into multiple packages as is custom under Debian (I don't really know about Arch). > > To make best use of Infinality patches, you need three libraries tailored to > properly work together: > > 1. freetype2 -- in my project freetype2-infinality-ultimate, > 2. fontconfig -- in my project fontconfig-infinality-ultimate, > 3. cairo -- again, in my project, cairo-infinality-ultimate. > > Each component is built separately and serves a different purpose. I'm currently > working on a documentation that would cover in details what a maintainer of the > packages for their distros should take care of in order to create a fully > working and robust Infinality environment, the same one I develop for Arch > Linux. Briefly, take a look at the pkgbuild branch of the GitHub repo and > inspect three top-level packages: freetype2-iu, fontconfig-iu and cairo-iu. The > `prepare` arrays in respective PKGBUILD scripts will give you an idea as of > which patches should be used for each package, and `package` arrays which > additional files should be copied during installation. It's actually a pretty > straightforward process: copy & paste & a bit of logic will do most of the job. > >> BTW, to what extent is it obligatory to have the fontconfig infinality patches included? Are those required for basic functionality, or do they "just" provide goodies like per-font tweaking? > > fontconfig-infinality-ultimate is a required component of the > Infinality-compliant software collection, as is my infinality-settings.sh. > > >> I didn't think of making a screenshot before installing the variant > > Just for the record: this is what Novarese Bk BT Bold looks like on my machine > (all the pieces of software and config files come from my repo; I just created > an additional fontconfig config file for the Novarese font): > > http://bohoomil.com/img/arch_shots/2014-06-24_novarese-bold-gtk.png > http://bohoomil.com/img/arch_shots/2014-06-24_novarese-bold-ff.png > > Well, I hope you'll find any of the above snippets handy. Good luck and happy > tweaking. ;) > > Best regards, > > bohoomil >

1 1

Re: [Xquartz-dev] Xquartz-dev Digest, Vol 72, Issue 2
by "René J.V. Bertin" 25 Jun '14

25 Jun '14

On Jun 25, 2014, at 21:00, xquartz-dev-request(a)lists.macosforge.org wrote: > > We just have --without-png. If there's an --enable-better that Linux distros are using, please let me know ;) I saw that MacPorts freetype is built --without-harfbuzz too. > >> and using the same runtime configuration? > > Obviously not the last one. Linux and darwin have different runtimes, but freetype shouldn't be caring about those differences. darwin Libc should behave similarly to glibc. I wasn't referring to that runtime, but to the functionality provided through fontconfig. As you probably saw in bohoomil's mail,a substantial part of the infinality patches has already been included in "stock" freetype, but rendering is also under control of a number of parameters. I've never looked at those on OS X, but I do know that I didn't have a ~/.fonts.conf -> ~/.config/fontconfig/fonts.conf (and when I copied one over from Linux, it seemed to be ignored). > > Yeah. I'm not really a fonts guy. If someone points out "hey, enable this option in freetype as it makes it better", I'll do it (or at least try it out in a beta). OK then, here's the stuff you could play with: bohoomil's "ultimate" freetype patches are here, as well as the script used for building on Arch: https://github.com/bohoomil/fontconfig-ultimate/tree/pkgbuild/01_freetype2-… "fontconfig-ultimate" patches and per-font rendering databases as well as the sh/bash shell profile (infinality-settings.sh): https://github.com/bohoomil/fontconfig-ultimate/tree/master the build scripts for "fontconfig-ultimate": https://github.com/bohoomil/fontconfig-ultimate/tree/pkgbuild/02_fontconfig… Or, you could wait a couple of days until I upload modified freetype, fontconfig (and cairo) ports to MacPorts trac that'll allow to install +infinality variants of those ports and see for yourself if the result is worth the effort of including the above. René

1 0

Re: [Xquartz-dev] Xquartz-dev Digest, Vol 72, Issue 1
by "René J.V. Bertin" 24 Jun '14

24 Jun '14

On Jun 24, 2014, at 21:00, xquartz-dev-request(a)lists.macosforge.org wrote: > Send Xquartz-dev mailing list submissions to > I'm not sure why you think rendering quality is "considerably less good under XQuartz than it is on "stock" linux" ... do you have examples? We're using the sam freetype in XQuartz that Linux is using. Is there something I'm missing? You're using the same freetype, but built with the same options, and using the same runtime configuration? It's hard to give examples of something that's subjective to a large extent. Let's put it this way, I'm not the only one convinced that the result is largely worth the effort of installing a freetype with the patches. R.

2 1

Infinality
by "René J.V. Bertin" 24 Jun '14

24 Jun '14

I brought up the idea of adding a Macports freetype variant that includes the Infinality patches, and Jeremy suggested I repeat the suggestion on here. >> What is infinality? > They're a set of patches that aim to improve font rendering quality. With them, quality is at least as good as it is under MS Windows or Mac OS X, possibly even better (with the usual personal taste caveats). > http://www.infinality.net/blog/infinality-freetype-patches/ I will see how straightforward it is to build the freetype from MacPorts with these patches, and if there's a quality gain. I sure hope so; the gain is visible under Linux (though not as spectacular as it apparently was), and font rendering quality is considerably less good under XQuartz than it is on "stock" linux (IMVHO). R.B.

2 1