[Issue 88613] Canvas: cairo-based font rendering

hdu at openoffice.org hdu at openoffice.org
Thu Apr 24 08:54:18 UTC 2008

To comment on the following update, log in, then open the issue:

User hdu changed the following:

                What    |Old value                 |New value
                  Status|NEW                       |RESOLVED
              Resolution|                          |LATER
        Target milestone|---                       |OOo Later

------- Additional comments from hdu at openoffice.org Thu Apr 24 08:54:15 +0000 2008 -------
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 

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.

Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.

More information about the fonts-bugs mailing list