Apache OpenOffice (AOO) Bugzilla – Issue 10843
OOO_STABLE_1_PORTS/X11: Mac native .dfont recognition in psprint/vcl
Last modified: 2007-02-05 03:27:45 UTC
Patches implement preliminary .dfont support for Mac OS X. Contributed by Dan (psprint) and Ed (vcl). Further fixups: 1) Make sure encoding support is correct 2) Treat .dfonts as TrueType Collections because they can store multiple fonts in one file. 3) Code cleanups 4) Factor out Mac OS X specific code into a separate dylib so we work on Darwin too
Created attachment 4395 [details] cd to SRC_ROOT/psprint, patch -p0 < /path/to/patchfile Implements recognition of Mac native fonts for psprint.
Created attachment 4396 [details] cd to SRC_ROOT/vcl, patch -p0 < /path/to/patchfile Allows Freetype (from Apple's X11) to recognize Mac native fonts discovered by psprint. Also adds Lucida Grande UI font support.
Note: Both 012203 patch treats Mac TrueType dfonts as TrueType collections (ie more than one Font/face in a single file) and allows multiple faces to be used from the same file. Further work: 1) Encoding cleanups 2) Code cleanups 3) Factoring out to external dylib so we can run on pure Darwin Dan
Created attachment 4397 [details] cd to SRC_ROOT/tools, patch -p0 < /path/to/patchfile Adds sal locale discovery support to tools in GetSystemLanguage()
Dan: In convertTrueTypeName you use osl_getThreadTextEncoding for all mac encodings; this probably only works as long as you are working in the correct locale. I think abetter way of doing this would be a switch statement like e.g. this: if ( pNameRecord->platformID == 1 ) { rtl_TextEncoding aEnc; switch( pNameRecord->encodingID ) { default: case 0: aEnc = RTL_TEXTENCODING_APPLE_ROMAN;break; case 1: aEnc = RTL_TEXTENCODING_APPLE_JAPANESE;break; case 2: aEnc = RTL_TEXTENCODING_APPLE_CHINTRAD;break; case 3: aEnc = RTL_TEXTENCODING_APPLE_KOREAN;break; ... } aName.append( OStringToOUString( OString((sal_Char*)pNameBuffer, pNameRecord->slen), aEnc ) ); } else ... judging from rtl/textenc.h we do not have all 31 *_APPLE_* encodings documented in the OpenType documentation, but quite a lot are available.
Ok, will do. dan
One question: Should I use the Platform Specific Encoding ID for the name, or the Language ID? The Apple documentation seems to indicated that the name in the 'name' table is encoded in the encoding specified in the Language ID, but there are a heck of a lot more of those than there are PSEIDs. Which one? Dan
I think the encoding id means the actual encoding of the name while the lang id describes the language in for which the entry is intended; e.g. Roman encoding contains all glyphs for Western languages (e.g. English, German, French). So names for the US, Germany and France would all have encoding id 0 but differ in language id. If you want to support the language ID, you would have to modify analyzeTrueTypeFamilyName which already does this according to the currently used language for MS language ids; it would be more difficult for the Apple IDs since one would have to map them; i think for this preliminary version it is not worth the effort, these things will be fixed with a genuine Aqua version.
Major change for native font support: we are going to use Fondu to convert all the Mac native fonts (at install time) to .ttf files, with _one_ face per file. This corrects a whole host of problems. The problems with the fully-native, dynamic font patch were: 1) Ate lots of ram because cannot mmap() resource-based fonts, have to copy to mem 2) Ate more ram because the copy to mem happens 3 times 3) Have to modify Freetype to be aware of > 1 face per file 4) have to modify both psprint and vcl to be aware of > 1 face per file So, all of these problems will go away because we can, using Fondu, make sure that all fonts have only 1 face per file. Therefore we can use an unmodified Freetype, keep all the original code in the vcl and psprint, and not have to worry about wierd fonts in various places in the system folders. Implementation on modified plan has started. Dan
*** Issue 10803 has been marked as a duplicate of this issue. ***
Created attachment 5117 [details] cd to psprint, patch -p0 < /path/to/patchfile Allows psprint to read and print most Mac fonts, when converted wtih Fondu
Created attachment 5118 [details] cd to vcl, patch -p0 < /path/to/patchfile Allows the vcl to recognize and display Mac fonts when converted with Fondu
Native Fonts v4: psprint.NATIVEFONT4.PORTS.diff vcl.NATIVEFONT4.PORTS.diff These patches require the fonts to be converted with Fondu and placed into the OOo fonts folder (share/fonts/truetype). The implement minimal kerning for Mac fonts, and allow recognition of Unicode character maps in Mac fonts. Other changes include antialiasing everything in the UI, as well as returning only the first font a device supports when getting its default font. Please approve both patches for commit to OOO_STABLE_1_PORTS.
Hi Dan, I looked at both your NATIVEFONT4 diffs and they look good but I don't feel qualified to approve these. Perhaps Philipp can approve them. I did have one question: Why do you need the following: +inline sal_uInt32 getUInt32BE( const sal_uInt8*& pBuffer ) +{ + sal_uInt32 nRet = (((sal_uInt32)pBuffer[0]) << 24) | + (((sal_uInt32)pBuffer[1]) << 16) | + (((sal_uInt32)pBuffer[2]) << 8) | + (((sal_uInt32)pBuffer[3]) ); + + pBuffer += 4; + return nRet; +} + Unless I am really confused here, the PowerPC processor is a BigEndian processor (although it can actually run in little endian mode also) it is used as BigEndian under Darwin, PPC Linux, AIX, PPC 64 Linux, etc. So the natural byte order for loading 4 btyes will be in the order your you are loading above (most-significant byte first - ala big endian) so I do not hink you would need the loads by bytes and shifts unless you were running this code on a little endian box. Now x86 is littleendian so I could forsee someone using this code from x86. Is the code that invokes this MacOSX specific or is it cross-platform? If MacOSX specific you should not need to write it that way for efficiency sake. If corss-platform, then yes this is the right way to force read a bigendian value on both big endian and little endian machines. Sorry I can' be more help but I think if we ask Philipp he can probably approve this easily. Kevin
Kevin, This could be used on x86 to use Mac TrueType fonts converted with Fondu. dan
some comments: in vcl/unx/source/gdi/gcach_xpeer.hxx you patch the following: +#ifdef MACOSX void (*pXRenderCompositeString16)(Display*,int,Picture,Picture,XRenderPictFormat*,GlyphSet,int,int,int,int,unsigned short*,int); +#else + void (*pXRenderCompositeString32)(Display*,int,Picture,Picture,XRenderPictFormat*,GlyphSet,int,int,int,int,unsigned*,int); +#endif why ? It breaks the build on other platforms. I checked against OOO_STABLE_1_PORTS and there was no 32 version. the changes in outdev3.cxx:GetDefaultFont: i'm not sure what you intend to do here. I'm also quite sure it will have no negative effect though. The rest of the NATIVEFONT pathces seemed good to me. The tools patch does not seem to be against OOO_STABLE_1_PORTS as it fails to apply.
pl, I just checked, and there _are_ #ifdefs around the correct code in gcach_xpeer.cxx in PORTS, so this code should compile fine. All other platforms will use 32 while Mac OS X will use 16. This change brings us up to 644 for gcach_xpeer.*. For the GetDefaultFont(), we are attempting to return _only_ the first font that the device supports, given a string of fonts separated by ";". This code does that. Before, we'd get a long list of fonts rather than just one. Also corrected what I thought was a bug in the "pSearch3" thing there. I will have to check out the tools patch. Dan
Created attachment 5256 [details] cd tools, patch -p0 < /path/to/patchfile REPLACES 012203 tools patch.
Philipp, Can you look over the patches again and approve for commit? Thanks, Dan
There is still the issue with the missing #ifdefs in salgdi3.cxx (for pXRenderCompositeString32); i'll attach an alternative patch that does this. By the way, why not use the *32 function on MacOS, too ? We wouldn't need an #ifdef at all. apart from this issue it looks good, approved
Created attachment 5266 [details] revised vcl patch
Created attachment 5287 [details] revised patch, Allows Mac OS X to now use XRenderCompositeString32()
Philipp, Can you look over the vcl.NATIVEFONT4.PORTS3.diff patch? I've now removed XRenderCompositeString16 from the Mac stuff to bring it in line with 644. So, please approve for commit all these patches: vcl.NATIVEFONT4.PORTS3.diff tools.macfont.OOO_STABLE_1_PORTS.032603.patch psprint.NATIVEFONT4.PORTS.diff Dan
looks good, approved
Approved files committed to PORTS. MERGE: vcl.NATIVEFONT4.PORTS3.diff tools.macfont.OOO_STABLE_1_PORTS.032603.patch psprint.NATIVEFONT4.PORTS.diff Dan
Created attachment 5299 [details] cd to vcl, patch -p0 < /path/to/patchfile REQUIRES the vcl.NATIVEFONT4.PORTS3 patch. corrects typecast error that broke compile
vcl.xrender patch corrects a typecast error in salgdi3.cxx. Please approve for commit to PORTS. Dan
I dif not find that one; in the PORTS2 patch i changed the signature in gcach_xpeer.hxx so it uses sal_uInt32* instead of unsigned* since sal_uInt32 is supposed to be a 32 bit integer on all platforms. But on second thought this is actually wrong, since the render header requirses unsigned int*, so instead of the cast really the pointer type should be changed (i think they should have used CARD32, but maybe that's just me). I'll attach a revised patch.
Created attachment 5308 [details] another path revision
Created attachment 5320 [details] cd to vcl, patch -p0 < /path/to/patchfile Corrects typecast from previous 032703 vcl.xrender patch
Philipp, Can you approve the vcl.xrender.032803.patch for commit to PORTS? Thanks, Dan
looks good. approved
vcl.xrender.032803.patch committed to PORTS. MERGE: -------------------------------------------- vcl.NATIVEFONT4.PORTS3.diff tools.macfont.OOO_STABLE_1_PORTS.032603.patch psprint.NATIVEFONT4.PORTS.diff vcl.xrender.032803.patch
A long story finally comes to a happy end ... :-)
Fixed in 103 GM. Never gonna get full native .dfont support until Aqua.
Sad story, but dfont support will not exist until Aqua port is finished. James McKenzie
Closing issue. James McKenzie