#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Changes (by jmr@…): * cc: dports@… (added) * port: texlive-bin,freetype => texlive-bin freetype -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by dports@…): I don't think that's quite correct -- freetype's --without-old-mac-fonts appears to disable all of the Mac-specific API, including FT_GetFilePath_From_Mac_ATS_Name, which doesn't seem resource-fork- specific. That's what xdvipdfmx is looking for. -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by dports@…): Does this patch solve your problem? (patch is against `port dir texlive- bin`; make sure you're using the regular freetype without --with-old-mac- fonts, and build texlive-bin +atsui) -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by pguyot@…):

...

"Old Mac fonts" are those having a resource fork. As far as I remember, Tiger was the last time Apple shipped any of those; since Leopard, it has shipped fonts using the data fork only. If tdvipdfmx checks for freetype's ability to load resource-fork-based fonts as some kind of indication of whether it can work at all on a Mac, then that sounds like a bug in tdvipdfmx that needs to be fixed. I don't think that's quite correct -- freetype's --without-old-mac-fonts appears to disable all of the Mac-specific API, including FT_GetFilePath_From_Mac_ATS_Name, which doesn't seem resource-fork- specific. That's what xdvipdfmx is looking for.

Not passing --with-old-mac-fonts to freetype does more than just dropping support for resource-based fonts. It entirely disables dependency on OS X frameworks, including the {{{FT_GetFilePath_From_Mac_ATS_Name}}} function which is not resource-fork specific. In fact, it removes all Mac-specific code. The real issue with gd2 was not the use of these functions, it was that freetype is linked with a framework whenever --with-old-mac-fonts is passed. This is different but not totally unrelated to [http://openradar.appspot.com/7209349 radr://problem/7209349] : strange things happen when a framework is first loaded within a non-main thread. The [http://openradar.appspot.com/7209349 radr://problem/7209349] bug is not fixed in 10.6.8 (did not test it in 10.7 yet), but the gd2 bug may have been fixed in 10.6. Hence my question about the current state of gd2 and bug #15909 because passing --with-old-mac-fonts on OS X seems a good idea (using Mac-specific code provides better handling of Mac fonts) and it is probably what other distributions of texlive do.

The functions it needs are simple enough that we could probably build them into xdvipdfmx without too much trouble, though... Does this patch solve your problem? (patch is against port dir texlive- bin; make sure you're using the regular freetype without --with-old-mac- fonts, and build texlive-bin +atsui)

I thought about providing just the functions indeed, yet tests I have just conducted with your patch show it is not sufficient. For the record, I do not think it is related to the ATSUI problem of texlive. ATSUI is deprecated and most functions are just no longer available on 10.7 and on 10.5+ 64 bits. However, the ATS functions xdvipdfmx and Freetype need/use have no equivalent in CoreText and therefore are still available, although not recommended, even in 10.7 according to [http://developer.apple.com/legacy/mac/library/documentation/Carbon/reference...]. Your patch compiles fine (generates a 64bits binary) without +atsui, even if the line you added within the "if {![variant_isset atsui]}" block is removed (i.e. xdvipdfmx is linked against ApplicationServices). However, passing --with-old-mac-fonts to freetype does more than just providing the couple of functions that was missing to xdvipdfmx. It provides an alternate version of FT_New_Face which, I believe, is able to look into dfont files beyond the first sfnt with the help of parameter {{{face_index}}}. I did several tests with a simple tex file that uses *.dfont fonts available in 10.6.8 in /System/Library/. You'll find attached the (newer) diff to texlive-bin that I used for these tests (allowing a non-atsui 64bits xdvipdfmx build that links against OS X frameworks) as well as several outputs. You'll notice that Courier does not work, but other fonts only work in all their styles if Freetype is compiled with --with-old-mac- fonts only. The PDFs were generated with {{{xelatex test.tex}}} which invokes xdvipdfmx by default. After this test, I strongly suggest rehabilitating --with-old-mac-fonts to Freetype. I wanted to test with +atsui, but texlive-bin currently does not compile with +atsui (this should be in another ticket...) -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by pguyot@…): Freetype should be able to handle dfont files on non-Mac builds. Yet, without --with-old-mac-fonts, freetype does not return the proper font to xdvipdfmx as shown by the tests I ran. If texlive-bin is compiled as on non-Mac (i.e. as in trunk), xdvipdfmx fails in cidtype2.c, line 969 : {{{ #ifdef XETEX_MAC /* disable the index check here because of how .dfonts are handled */ offset = 0; #else if (opt->index > 0) { ERROR("Invalid TTC index (not TTC font): %s", name); } else { offset = 0; } #endif }}} This is because opt->index is greater than 0 which is the index of the style in the given face (and might refer to the index of the sfnt resource ?). -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by pguyot@…): freetype is able to parse dfont files that contains several sfnt resources that contain a single font each. It cannot handle dfont files that contains one or more sfnt resources that contain several fonts. But this is not the case here. See the 2006 introduction to the code handling this here : [[http://lists.gnu.org/archive/html/freetype- devel/2006-10/msg00025.html]] However, freetype computes face_index differently when --with-old-mac- fonts is enabled. When this option is not enabled, it uses a POSIX- compliant resource fork parsing code that probably index sfnt resources in the stream order. When this option is enabled, it uses Get1IndResource which gets resources in ascending ResID order if I remember correctly. On the other hand, xdvipdfmx (normally) on non-Mac platforms uses fontconfig and the index it is passed, but will just fail to parse truetype fonts with an index greater than 0. On Mac, xdvipdfmx gets the face index from FT_GetFilePath_From_Mac_ATS_Name, which happens to be compatible with the index computed by Get1IndResource. The proposed patch (texlive-bin.patch and the updated version texlive- bin.2.patch) gets xdvipdfmx to use FT_GetFilePath_From_Mac_ATS_Name without freetype --with-old-mac-fonts. Therefore, xdvipdfmx will invoke freetype with a face_index that will not match the proper style, as freetype expects an index based on the stream and not based on the ResID. As a result, styles will get mixed as shown in the PDFs that were generated and attached to this ticket. However, this does not explain the output of Helvetica Neue Medium and Helvetica Neue Condensed Bold... Besides configuring freetype with --with-old-mac-fonts, two other fixes are possible : * get xdvipdfmx to handle TrueType fonts with an index greater than 0. Just replacing {{{#ifdef XETEX_MAC}}} with {{{#ifdef XETEX}}} in the snippet above does not work, though. * get freetype to index fonts alike with or without --with-old-mac-fonts (except for the FOND/sfnt difference ?) and compile xdvipdfmx according to the proposed patch (i.e. to use FT_GetFilePath_From_Mac_ATS_Name). -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Comment(by dports@…): So does everything work OK with that patch? If so, that seems like the best approach. I'd be in favor of using --with-old-mac-fonts if it would work, but it sounds like the problems with that (#15909 etc) were pretty bad and I don't see any indication they've been fixed. -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:13> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved ---------------------------------+------------------------------------------ Reporter: pguyot@… | Owner: dports@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: haspatch | Port: texlive-bin freetype ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * cc: dports@… (removed) * keywords: => haspatch * owner: macports-tickets@… => dports@… -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:15> MacPorts <http://www.macports.org/> Ports system for Mac OS

#30745: xdvipdfmx not able to use /System/Library/*.dfont fonts, freetype --with- old-mac-fonts involved -----------------------------------+---------------------------------------- Reporter: pguyot@… | Owner: dports@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Resolution: fixed | Keywords: haspatch Port: texlive-bin freetype | -----------------------------------+---------------------------------------- Changes (by dports@…): * status: assigned => closed * resolution: => fixed Comment: r82979. -- Ticket URL: <https://trac.macports.org/ticket/30745#comment:17> MacPorts <http://www.macports.org/> Ports system for Mac OS