Created attachment 51071 [details]
before pic

Created attachment 51072 [details]
post cairo pic

Created attachment 51073 [details]
"proto" patch

Cool! I like it.

Created attachment 51074 [details]
updated patch

patch now additionally handles text colour, clipping region and vertical text

This would be a nice feature for OOo3.0.

The clipping is currently limited to rectangular regions? Though we are using similar code in DrawServerAAForcedString to get the maximum bounds of the background, when actually painting the 
GCs with detailed clipping are used.

For dynamic loading of the symbols the new fangled osl_getAsciiFunctionSymbol is nice...

Well the clip was just a quick hack, cairo is capable of arbitrary clipping. I
was just too lazy to figure out the right way to convert it yet.

I've to figure out how artificial emboldening and italicization works too.

No problem.
Do you happen to know of any binary compatibility issues between cairo versions for the APIs we want to 
use?

@PL: is there any scenario where the plugins get loaded after the first text output?
I'm also a (very) little worried about getting exactly the right library. When we know the exact library we 
could also enable it for the generic-X11 vcl plugin.

If someone tried to output text before loading the plugin it would fail (best
case) or crash (probably) since there is no display connection yet, no SalLayout
factory, no bitmap factory, no everything. Also no OutputDevice could have been
created yet since they all create a SalFrame, SalVirtualDevice or SalPrinter,
which would most probably crash also. Since there is no place to draw text to I
think it is impossible that there is someone to call DrawText before one of the
plugins is loaded.

I don't know of any incompatibilities (yet). Wrt. the ordering I don't *think*
there is any route to output text to a drawable used before a vcl plug has been
loaded. If there is then we simply will render with the existing non-cairoized
renderer for the lifetime of that OOo instance so it's not a massive disaster. 

Of course all I'm really focused on at the moment is the gtk vclplug, so in that
scenario in a modern gtk2 libcairo is already loaded by the time we get to any
text output, hence the NULL module handle I pass in in this demo.

The libs to force in should just be "libcairo*.so.2" I believe.

Though at the moment the tricky bit is fake bold and fake italic, lets see how I
get on with that first.

I like the general direction here. ;-)

Created attachment 51104 [details]
updated patch

And that adds specific clipping, artificial italic and artificial bold. Though
I'm thoroughly unhappy with the emboldening, the only way I can see to tell
cairo to embolden is through the fontconfig pattern api which I don't want to
use and don't need for anything else.

I'll check with the cairo guys if there's a better way to do it, or if there's a
planned api for it which could be used in the future. Otherwise I reckon I'm
better off just falling back to the existing rendered for emboldening and
removing the vomit.

Created attachment 51107 [details]
ah, rotate and *then* scale

Created attachment 51108 [details]
writer test-case

export SAL_ENABLE_CAIROTEXT=1 to enable it, emboldening disabled for now.

Is it just me, who finds it weird that OOo has cairo in canvas module that does
extra trickery to use fonts in VCL. Additionally, with cws cairoquartz01, the
cairo canvas would have support for win32 and Mac OS X too. Thus cairo-made
fonts could possibly make sense to non-Linux too...

Or is this something completely different? 

@mox: Yes, drawing glyphs on the cairo canvas via cairo is not a bad idea. Positioning these glyphs should 
be done like for their VCL counterparts though. If cairo doesn't do something fancy for drawing these 
glyphs (doesn't it use Aqua/Win's native rendering?), then there it doesn't make much of a difference 
though.

@hdu: yes, canvas is on Mac supposed to use native font code of VCL. Although
due to some bug this is not actually working for cairocanvas (on Mac).

The longer term thing that I'm talking about is that just like cairocanvas has
single implementation used by multiple platforms(see cws cairoquartz01), the
font rendering (for canvas) could also have only one (cairo) implementation, and
thus less platform specific code in OOo.

done in cairotext01

reassigning for qaing in cairotext01. Possibly only visible to the naked eye
with e.g. xmag, but I'm a bit blind. Text positioning itself does not change at
all. Kicks in when a sufficient cairo has already been loaded, i.e. gtk vclplug
on a modern distro.

On my system there was a race between the first text rendering and loading the cairo lib indirectly via the 
gtk plugin, so the feature didn't work. While fixing this cairotext now also gets enabled for the generic 
and the kde vclplugin.

@cmc: Oops, I hadn't noticed that the CWS already had its status changed. Sorry for checking something 
in after that.

Reassigned to me (ES on vacation).

Verified in CWS cairotext01.

*** Issue 3886 has been marked as a duplicate of this issue. ***

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues