Apache OpenOffice (AOO) Bugzilla – Issue 88613
Canvas: cairo-based font rendering
Last modified: 2017-05-20 10:27:53 UTC
Now there are cairo-based Canvas backends for Unix/X11, Windows and Mac/Quartz. The text rendering, however, is always directed back to VCL. To take the full advantage of cairo library, and it's support for cross-platform text layout and rendering, the XCanvasFont and XTextLayout interfaces need to be implemented "natively" with cairo.
Created attachment 53121 [details] The "unthinkable" hack - brute force the text rendering in cairo, instead of VCL
With the very crude patch above, I'm able for the first time to see text in the cairo canvas backend using Mac OS X / Quartz. A half-way solution would be to use, in cross-platform way, the "SalLayout" -based cairo text rendering, as already used by UNIX/X11 in vcl/unx/source/gdi/salgdi3.cxx --- particularly this function: void X11SalGraphics::DrawCairoAAFontString( const ServerFontLayout& rLayout ) The ultimate solution would be to get rid of as much of VCL and VirtualDevices as possible in cairocanvas backend, and use the available cross-platform cairo API instead: http://www.cairographics.org/manual/ The cairo API fully supports font rendering, but does not currently provide full support for text layout. Thus, for layout, parts of the VCL, or the native backends, would still need to be re-used.
From a distributor point of view not having OO.o behave as a one-of-a-kind for text rendering would be a huge boon. Please adopt the same text layout and rendering stack as other FLOSS applications (that is to say fontconfig + freetype +pango/harfbuzz + cairo on the Linux side). I suppose there would be a lot of commonalities with Firefox, so working with them on a common set of solutions would be great. http://www.freedesktop.org/wiki/TextLayout http://www.freedesktop.org/wiki/TextLayout2008Attendees
Hi, I agree that using pango/harfbuzz for layout, instead of the OOo-specific one is highly desired. However, to be eligible as a replacement for VCL (and justify the amount of work), it would need to provide SAME or BETTER font layout as VCL does currently AND have that level of quality as CROSS PLATFORM library. Just porting one platform is not enough. So a layout replacement would need to support equally well AT LEAST - Unix/X11, Windows and Mac OS X. Preferably using platform native functions on Win/Mac when possible, while ensuring there are not major differences on layout on different platforms. (Mozilla/Firefox is aiming at "no differences", I guess).
The original issue here is that the current OOo-Canvas based on cairoquartz doesn't render text yet. Since Quartz can render beautiful text in its sleep if it gets a proper Quartz CGContext, I'm very sure this is a bug in the cairoquartz01 child workspace. I'll debug into it when I'll resync CWS aquabmpfixes01 to something >= DEV300_m6. Other than that I'm afraid this issuezilla item is already drifting way off topic. I'll comment only ONCE on the other suggestions here. If needed please open focussed issues. --- Great ideas here! Thanks! I'll get right on it! On a second thought some Pango related questions come to mind: P1.) is Pango's layout engine that much better than Apple's native ATSUI or CoreText? P2.) is it at least that much better than Window's native Uniscribe? P3.) what are the specific benefits over ICU's layout engine that OOo uses on Unix? do specific http://bugs.icu-project.org/trac bugs have showstopper qualities? P4.) isn't Pango being obsoleted by HarfBuzz / Graphite on Unix? P5.) wouldn't we loose the "justified text" feature, that some/most author prefer? Also some related questions about Cairo's text rendering: C1.) is it that much better than Apple's native ATSUI or CoreText? C2.) is it at least that much better than Window's native Uniscribe? C3.) since CWS cairotext01 (http://eis.services.openoffice.org/EIS2/cws.ShowCWS? Path=SRC680%2Fcairotext01) our Unix port supports it already It used to be better because of subpixel-rendering, but nowadays distributions switched exactly THAT feature off, so what are the remaining killer features? Speaking of text rendering on Unix I'd like to mention that during the live-time of OOo's unix codebase Xft (now unmaintained), STSF (now unmaintained) and "pure" XLFD were "the right thing to do" de jour. The answers to P1/P2/C1/C2 are such that even Pango itself just wraps the native layout engines. And since OOo uses UTF-16, Pango's interface is UTF-8 and the native layout engines are using UTF-16 again the roundtrip would be a nice way to warm up the cpu. For nothing! But getting rid of native text justification and losing access to the real layout engines for their potential advanced typography features. I'd also like to mention that a major difference between a browser and a word processor is that a browser aims especially for screen rendering whereas a word processor usually targets a non-screen device. In other words: most people would complain if their document's pages re-flowed when they changed the word processors zoom level (which corresponds to a Browser's default text size setting). This difference is responsible for application-layer problems like issue 88539 (Writer rendering), issue 51508 (Calc rendering) or issue #thb# (Impress rendering). Since people especially mean these issues when they comment on OOo text rendering problems they would be surprised that even if we did the herculean task to rip out the guts of GSL to replace it with the "recommended stack" these problems (and other niceties like issue 79878!) would remain just as before.
Hi hdu, thanks for the comments. I also don't want this issue to become endless tug war, so I just clarify some things. Note that I don't really have a perfect solution to offer, neither I'm expecting the text layout to be solved anytime soon. ... Yes, the quartz failing is just a bug, and does not need the level of changes that I'm describing here. The core of the discussion is that OpenOffice.org has been and in many respects is still not proactive in integrating with the other open source projects, causing OpenOffice.org to remain a huge, non-shared (with other projects) codebase. This means OOo needs to have e.g. it's own set of developers for all of text rendering and fonts, because no other project is working on that code. The reason for working with cairo based font rendering and layout is the same as using cairo library anywhere in the OOo: Yes, OOo could do everything by itself with directly using functions of native platforms + OOo specific crossplatform layer. However, OOo can also use cairo (among others) as the crossplatform layer, that can REMOVE the code that OOo currently has. While it creates another layer of API, if it (eventually) can become the only API (just like Mozilla Firefox 3 has), then the rest of the OOo code can be optimized for that API. And OOo developers can also work with cairo developers to improve that library (which already pretty good exactly thanks to contributions from MULTIPLE independent projects). => more shared code, less OOo-specific code. ... For graphics rendering cairo is the unquestioned choice. It seems to be a good choice for font rendering too. To me, text layout is completely unknown area. I do know that pango nowadays uses harfbuzz, which is a collaborative project between Gnome and KDE. So that's pretty good coverage on UNIX/X11. However, high quality crossplatform support is the key here. Only X11 is not enough. ... So currently I'm targetting just font rendering, and hoping a good layout solution comes up some day. And I'm not saying things cannot go to the other direction too. For example on UNIX, hunspell has originated from inside OOo and now distributions are standardising on it, and replacing the aspell/pspell/myspell alternatives. That's not crossplatform, but it's a nice step forward. If OOo's text layout is superior to others, why not create a crossplatform textlayout module -- with "libtextlayout" -library that can then be used by other projects (and is nicely isolated for OOo)? It would need to become an independent hunspell-like "sourceforge" project (i.e. outside of OOo CWS hassles and schedules) to truly enable sharing and collaboration. ... Open source gives best results when you are proactive with ways of sharing and collaboration.
Created attachment 53225 [details] Work in Progress - v2
With the WIP2 patch, I'm able to get fonts rendered in cairo with correct colors, size, bold/italic, underline, and shadow. Underlines and shadows seem to be rendered manually by the Canvas (not by the font). The patch is still using string based rendering (not glyph by glyph), so advanced layouting is missing. I'm getting the native font ID (with all the styling already set) for the selected VCL Font, and rendering with that native font. I needed to add an additional function: sal_IntPtr OutputDevice::GetFontId( const Font& rFont, float fExactHeight ); to get the native font id. I guess the long term solution would be to add struct SystemFontData to vcl/inc/vcl/sysdata.hxx and fill it appropriately. So on Mac, I can get cairo-rendered text with e.g. Zapfino font showing up nicely :) With 1 line of platform-specific code... This replaces the hundreds of lines of code of all the DrawText, DrawTextArray functions in vcl/source and their platform specific implementations. Any suggestions on how to get the glyph-by-glyph information with rendering::XTextLayout and/or from VCL is greatly appreciated.
> With 1 line of platform-specific code... This replaces the hundreds of lines of code of all the DrawText, DrawTextArray functions Great! If text justification, text decorations (like underline/strikethrough/emphasis marks), multi-line controls, etc. still work I'm quite impressed. Also supporting all the exotic use cases for rendering old metafiles would be nice. > Any suggestions on how to get the glyph-by-glyph information with > rendering::XTextLayout and/or from VCL is greatly appreciated use SalLayout::GetNextGlyphs() that interface is a little ad-hoc though and will be replaced by a container/iterator style interface, but the changes for users of that call will be trivial
Another comment: From my POV the harfbuzz project will be the "libtextlayout" of the FOSS world. On the other hand VCL's text layout main focus is to do the delicate balancing act between - not needing to rewrite all OOo application layer code from ground up - trying to give them support for the modern text layout So for writing new applications using OOo's wrapper layer around existing layout engines is not a good idea. But OOo will still be needed in the future. It could become much thinner though if the FOSS layout engines committed themselves to attack the really fascinating topic of full blown text justification and advanced typographic styles for OpenType (and eventually Graphite) fonts. Especially if the layout results were compatible with their counterparts from other platforms.
Created attachment 53263 [details] Work in progress v3
With the WIP3 patch I'm now using SalLayout for layouting (text to glyps) and then using ::getNextGlyphs and rendering with cairo_show_glyphs. Weirdly enough, this produces very ugly result (no proper layout adjustments done) and is much worse than using the cairo "toy" api, cairo_show_text directly. So something's still missing wrt. SalLayout stuff. I'll attach screenshots so you get the idea.
Created attachment 53264 [details] not so working...
Created attachment 53265 [details] fine except for rotated text
Created attachment 53266 [details] Reference image (using VCL canvas)
Ha! I take my words back. The cairo_show_glyphs IS better layed out, but looks uglier, because there is the fonts are rendered too small. The same problem existed with cairo_show_text too, but was not noticeable due to cairo doing smaller layout too.
Created attachment 53363 [details] WIP4 - on par with VCL, except some issues with logical advancements
BTW http://cworth.org/gtk+/hackfest_2008_03_11/
As is the patch will probably not go in (internal VCL API exposed). With the target "later" I also assume, that this needs further work, so I'll set the type from "patch" to "enhancement". This is merely to make this issue move out of the patch statisctics into which it does not seem to belong.
The work of this bug continues in cws cairocanvastext01. The cws now has working cairo canvas text for X11, Mac OS X/Quartz and (hopefully) Windows. The rendering is not 100% perfect, but several problems are actually due to VCL backends and/or canvas implementation, not the cairo text rendering. The internal VCL API is NOT exposed anymore. Instead, a platform independent glyph layout array + font id is passed to canvas, as described in vcl/inc/vcl/sysdata.hxx.
Fixed - Works ok for Linux & Mac/Aqua. Win32 should work too, but is untested and not mandatory for this cws cairocanvastext01. Cairo font rendering is used as the primary method, with VCL font rendering provided as fallback for some corner cases. You can use following file to check things: http://www.openoffice.org/nonav/issues/showattachment.cgi/55696/test2.odp Some known issues that are outside of scope for this cws are: issue 92657 - Color of dotted underline not supported in fullscreen presen issue 92658 - Wave underline not supported in fullscreen presentation (can issue 92659 - cairocanvas: Some Fontwork graphics are missing "holes" in l issue 92660 - cairocanvas/Mac Aqua: text rendered in VCL is not always vis
@thb: please verify in cws cairocanvastext01
Awesome work, I love it. Canvas changes verified. @hdu: could you please have a quick look at the vcl changes (that look good in general, but OutputDevice::GetLayoutData should rather skip the mtf action generation). Ok with the 3.1 target? The remainder is just merged from cairosource01 and thusly irrelevant.