74245 - [RFE] Use Quartz font rendering on Mac OS X

Status: VERIFIED DUPLICATE of bug 121540

(Core :: Layout, enhancement)

Description

[Henri Sivonen (:hsivonen)]

(This is really a gfx thing, but there isn't a component named gfx.)

Currently Fizzilla CFM uses the Mac gfx implementation. As a result, Fizzilla
doesn't get the benefits of Quartz font anti-aliasing. Instead, the old worse
font anti-aliasing is used. (On Classic, this could be fixed by installing
SmoothType.)

If Mozilla used Quartz for font rendering, the fonts would look better.
(Accessing non-Western-European glyphs might work better as well. I am not sure.)

Comment 1

[Erik van der Poel]

Not sure who owns Mac fonts. Over to Kevin for his guidance.

Comment 2

[Kevin McCluskey (gone)]

Reassigning to Don.

Comment 3

[Terence Tan]

There is a Quartz rendering library available for Carbon CFM applications 
(which is what we are, I think?)... it may be incomplete and might not offer 
the fine control of font rendering which we require, but we'll see. It also 
includes limited support for Mac OS 9, which should be fine as we don't support 
OS 9 under the Carbon build anyway.

I haven't gotten in touch with the author, maybe he'd be amenable to releasing 
his work under a free software licence.

http://www.latencyzero.com/macosx/cg/

Comment 4

[Steve K]

Terence,

I may be totally wrong, but I thought it is possible to use Quartz font
rendering on OSX.  That library looks like it is a partial attempt to implement
a similar API under carbon on OS9.

I think the right path for Mozilla would be to implement native Quartz font
rendering under Carbon/OSX, and keep the current font code for MacOS9 (classic
or, if we ever decide to build a carbon app targeted at OS9).

Right now, there are two different targets: the classic build for OS9, and the
Carbon build for OSX.  (while it may be possible to run either build on either
system, they are definately not tested much that way).

I would imagine that within a year or so, the CFM/OSX build will be where the
bulk of attention is paid.

Comment 5

[Henri Sivonen (:hsivonen)]

Core Graphics itself can be used from a CFM app. In that case, the Core Graphics
API functions have to be called throught function pointers. There a few lines of
sample code in Apple's Quartz Primer document.

It would be important to know whether acquiring a Core Graphics Context for a
GrafPort affects further QuickDraw calls on that same GrafPort.

I doubt using a Core Graphics clone makes sense on Mac OS 9.

Comment 6

[Frank Tang]

any sample code some where? 

Comment 7

[Henri Sivonen (:hsivonen)]

There are two PDF documents with sample code linked from
http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Quartz2D/quartz2d.html

Comment 8

[Mike Pinkerton (not reading bugmail)]

taking for investigation

Comment 9

[Patrick C. Beard]

I just checked in:

mozilla/gfx/src/mac/nsCoreGraphicsGlue.cpp

Which provides a random sampling of CFM callable glue functions for Quartz. I
took a macro based approach to writing the glue, which is easily extended.
Enclosing an experimental patch to mozilla/gfx/src/mac/nsRenderingContextMac.cpp
which uses Quartz to render ASCII strings, fills and frames rectangles. This
demonstrates that it is simple to incrementally start using Quartz, though the
code is far from optimal. We'd probably only want to create a CGContext once up
front, and transfer over Quickdraw states lazily. But it's a start, and it works.

The text rendering stuff is commented out, because it doesn't work for all
fonts. In fact, the Quartz documentation says that it uses Apple Type Services
to do the font rendering, which we do in the UNICODE case, so it might not
necessarily make sense to change our approach.

Comment 10

[Patrick C. Beard]

Attachment: Experimental use of Quartz in nsRenderingContextMac.

Comment 11

[Patrick C. Beard]

We should probably investigate "CFM late binding" as referenced by the author of
CoreGraphicsLib.

Comment 12

[Steve Dagley]

The CFM late binding info can be found at <http://developer.apple.com/samplecode/
Sample_Code/Runtime_Architecture/CallMachOFramework.htm>

Comment 13

[Mike Pinkerton (not reading bugmail)]

Attachment: quartz to render text and fill rects, hardcoded to helvetica

Comment 14

[Mike Pinkerton (not reading bugmail)]

i hardcoded beard's font stuff to always use helvetica and everything all draws
(modulo some measuring problems). Damn, does it look sweet. I took a screenshot,
but note that it doesn't look quite as good as it does on my screen.

My swag at this is one person, one month. Perhaps a bit less, but a month to be
on the safe side.

Comment 15

[Mike Pinkerton (not reading bugmail)]

Attachment: same shot, as png

Comment 16

[Henri Sivonen (:hsivonen)]

Very cool. Thank you for doing this.

I'm very eager to try it out. If you have time, it would be nice to have a build
avalaible for download.

Comment 17

[Zach Lipton [:zach]]

ooooh, pretty, would this work on mach-o (I'll try it if unknown, just don't 
want to if we know it wont work)

Comment 18

[Greg K.]

Would this give us access to the old fancy GX font extensions? I know that stuff
became part of ATSUI, and has also become part of Quartz.

We may need some AI to access those options, however, in the Font Prefs panel.

Comment 19

[Mike Pinkerton (not reading bugmail)]

zach: sure, there's no reason why this wouldn't work in the mach-o build.

Comment 20

[strobe anarkhos]

I would look into either ATSUI or MLTE (which uses ATSUI IIRC). Both can either
be used with QuickDraw or Quartz. This may also solve a host of unicode and
text-rendering problems which are scattered all over bugzilla. 

Comment 21

[Hervé]

please include Patrick's patch in OS X nightlies, it's urgent !

let me explain (sorry for the bad english) :

right now, Mozilla for OS X is so ugly compared to Aqua, that I can't even tell
people "try this browser, it's the fastest, the most compliant, it beats IE5.1
hands down on every aspect" because they answer me "are you kidding ? it looks
like a windows 95 app running on OS X". it's completely dishartening for Mozilla
supporters like me :-( 

i like OS X a lot, i like Mozilla, and i want to advocate for Mozilla on OS X,
but because of that fonts (and scollbars), i can't...

i know i'm not helping you much by telling you that. but i want to emphasize
that this look & feel problem (font, Aqua widgets) is somewhat "critical" to the
OS X port of Moz... maybe severity should be put up to "major" to reflect this
fact ?

--
Hervé - http://mozillazine-fr.org/

Comment 22

[Greg K.]

In all fairness, it should be noted that, among OS X browsers, only OmniWeb presently uses 
Quartz. None of IE, iCab, or Opera do; fonts look the same in them as in Fizzilla.

(Please, remember to limit advocacy to voting for the bugs, or discussion in the newsgroups.)

Comment 23

[strobe anarkhos]

In all fairness, it should be pointed out that OmniWeb breaks a lot of HI
guidelines, many of which really **** me off. For example you should only use
utility window title bars with utility windows. There is a reason why utility
windows don't have a disabled state OMNI!

Anyway I consider the event handling issue a billion times more important, and
after that fixing drag+drop.

Comment 24

[Ari]

Attachment: a slightly better hacky patch

I've been messing around with this for a while, and this is what I came up
with. The original patch didn't render all of the text that it was supposed to
because it was trying to set the font by passing the quickdraw font family name
to quartz. Quartz actually needs the postscript font name which, I think, can
only be retrieved using ATSUFindFontName(...). The new patch successfully
renders all text and preserves the text style. However, there are some weird
problems related to getting the bounds of the text that are probably caused by
the fact that we are using quartz to render the text but quickdraw to get its
bounds. Unfortunately, quartz only has very primative text handling and it may
not be easy to get the text bounds from it.

Also, converting nsRendringContextMac::DrawString(...) to use quartz doesn't
cover unicode text rendering. Unicode appears to be rendered by a combination
of quickdraw and atsui. The patch also includes a hack to make atsui use quartz
by passing it a CGContext. However, all of the text rendered by atsui is upside
down (I think it is mirrored about its baseline) and I can't figure out why. I
know that when you get a CGContext from a GrafPort, you need to flip the y-axis
and flip all text as a result. But the call to CGContextSetTextMatrix(...)
should flip it back in the same way that it does in
nsRendringContextMac::DrawString(...). Anyone have any ideas why this isn't
working in this case?

I think that if we can get atsui to use quartz properly, we should use it to
render all text even if it isn't unicode because it has built-in support for
things like getting the text bounds.

Comment 25

[Ari]

Attachment: hacky patch with reimplemented GetWidth(), working ATSUI

This patch gets ATSUI to use quartz by working around the upside down text
problem. It also includes a reimplemented version of
nsRenderingContextMac::GetWidth() that more accurately gets the width of quartz
rendered text.

We should still consider switching to ATSUI/MLTE entirely because the way we
seem to have to choose fonts in quartz (searching for the postscript name and
allocating a buffer for it) is pretty flaky. Also although the quartz
implementation of GetWidth() works, it's not perfect and I don't trust it to
work in all cases. For example, the fact that text sometimes shifts position
when it is highlighted seems to indicate that there is some inaccuracy in
GetWidth().

Right now nsUnicodeRenderingToolkit bends over backwards to avoid using ATSUI,
and even when its does, it only uses it to render one character at a time.

Anyone have any idea what we should do?

Comment 26

[Mike Pinkerton (not reading bugmail)]

have you seen 

http://developer.apple.com/qa/qa2001/qa1009.html

entitled "Why are my Core Graphics calls drawing upside down?" It might help.

Comment 27

[Ari]

I have seen that article but if you do everything that it says, ATSUI text will
be upside down because the y-axis is flipped by the scale by -1. Even if you set
the text matrix to flip the text back to being right-side up, ATSUI still draws
upside down because it appears to reset the text matrix on its own and ignore
any text matrix that was previously set.

At any rate, I got ATSUI working with the latest patch by not flipping the
y-axis and just negating the y-coordinate of the text location. See the comment
in nsATSUIToolkit::StartDraw() in attachment 62926 [details] [diff] [review].

Comment 28

[Ari]

I have also been communicating with people at Apple on the Carbon-Dev mailing
list. They have strongly and repeatedly recommended against using Quartz
functions directly like CGContextShowTextAtPoint() to draw anti-aliased text.
The reason is that CGContextShowTextAtPoint() only works with 7-bit ascii text.
In addition, the only way to set the font is using method in attachment 62926 [details] [diff] [review].
That method is unreliable because the font name that we try to retrieve is not
always encoded in Roman/English the current patch assumes. Also,
ATSUFindFontName() doesn't always find a name, and when that happens, no text is
displayed.

The Apple people say that CGContextSetFont() (which takes a CGFontRef instead of
a postscript font name) is not suitable for our purposes because right now it
only works with CGContextShowGlyphs().

The alternatives to using Quartz directly are:
1. TXNDrawCFStringTextBox(), TXNDrawUnicodeTextBox() - using ATSUI indirectly
2. ATSUDrawText() - using ATSUI directly as we do in part of
nsUnicodeRenderingToolkit()

The advantage of (1) is that it automatically creates a temporary CGContext to
draw into and automatically grabs font, style, and color settings from the
current GrafPort. 

The advatage of (2) is that there may be less overhead because (1) uses ATSUI
eventually anyway.

Both are not great for rendering non-unicode text because every time we wanted
to draw a non-unicode string, we would have to convert it to unicode. Also,
ATSUI is probably slower than quickdraw text (although we could make things
faster by caching ATSUStyles). Performance worries are exacerbated by the fact
that it looks like mozilla renders text in very small pieces and calls
DrawString() many times.

Comment 29

[Frank Tang]

what I herad from Apple's tech manager in Nov is apple discoruage us to use the
text drawing funciton in Quatz because of it's lack of international support.
And they suggest us use either ATSUI directly or higher level Theme font api. 

Comment 30

[Ari]

It seems that if we use ATSUI, we'll have to sack most of the code in
nsUnicodeRenderingToolkit which currently uses ConvertFromUnicodeToText() and an
intricate series of fallbacks.

What should we do?

Comment 31

[Simon Fraser [no longer active]]

See also bug 121540.

Comment 32

[Carsten Klapp]

Mike your example screen snapshot looks great, I'm looking forward to Quartz
anti-aliased text in Mozilla. OmniWeb is my primary browser only because of the
nicer looking text.

Thanks!! Carsten

Comment 33

[Mike Pinkerton (not reading bugmail)]

over to smfr to get it off my list.

Comment 34

[Simon Fraser [no longer active]]

Should this be closed out as a dup of bug 121540? It seems that ATSUI is the way 
to go for Core Graphics rendering, and hyatt sez that the patch in bug 121540 is 
way faster than this one. Comments?

Comment 35

[Ari]

This is a dup of bug 121540. I'm not at all surprised that using ATSUI is faster
than the patch attached to this bug because any attampt to use the CG text apis
directly results in a hacked-up mess.

Comment 36

[Henri Sivonen (:hsivonen)]

Actually, bug 121540 is a duplicate of this one. :-)

Comment 37

[Simon Fraser [no longer active]]

Bug 121540 (ATUI rendering) has patches and stuff.

*** This bug has been marked as a duplicate of 121540 ***

Comment 38

[Matt Perry]

Verified dupe