Issue 85470

Summary: render text with cairo
Product: gsl Reporter: caolanm
Component: codeAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues <issues.openoffice.org>
Severity: trivial    
Priority: P3 CC: hdu, issues, moxfox, oo, philipp.lohmann, thb
Version: 680m243   
Target Milestone: OOo 3.0   
Hardware: All   
OS: Unix, all   
Issue Type: ENHANCEMENT Latest Confirmation on: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 88973    
Attachments:
Description Flags
before pic
none
post cairo pic
none
"proto" patch
none
updated patch
none
updated patch
none
ah, rotate and *then* scale
none
writer test-case none

Description caolanm 2008-01-22 11:58:20 UTC
Attached is some sample experimentation code to play with rendering text with
cairo. Also attached is a before and after pic
Comment 1 caolanm 2008-01-22 11:59:22 UTC
Created attachment 51071 [details]
before pic
Comment 2 caolanm 2008-01-22 11:59:46 UTC
Created attachment 51072 [details]
post cairo pic
Comment 3 caolanm 2008-01-22 12:00:09 UTC
Created attachment 51073 [details]
"proto" patch
Comment 4 hdu@apache.org 2008-01-22 12:20:28 UTC
Cool! I like it.
Comment 5 caolanm 2008-01-22 14:25:40 UTC
Created attachment 51074 [details]
updated patch
Comment 6 caolanm 2008-01-22 14:26:17 UTC
patch now additionally handles text colour, clipping region and vertical text
Comment 7 hdu@apache.org 2008-01-22 16:01:55 UTC
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...
Comment 8 caolanm 2008-01-22 16:14:01 UTC
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.
Comment 9 hdu@apache.org 2008-01-22 16:50:53 UTC
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.
Comment 10 philipp.lohmann 2008-01-22 16:59:38 UTC
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.
Comment 11 caolanm 2008-01-22 17:03:13 UTC
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.
Comment 12 thb 2008-01-23 09:46:48 UTC
I like the general direction here. ;-)
Comment 13 caolanm 2008-01-23 13:05:02 UTC
Created attachment 51104 [details]
updated patch
Comment 14 caolanm 2008-01-23 13:08:23 UTC
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.
Comment 15 caolanm 2008-01-23 14:17:35 UTC
Created attachment 51107 [details]
ah, rotate and *then* scale
Comment 16 caolanm 2008-01-23 14:20:37 UTC
Created attachment 51108 [details]
writer test-case
Comment 17 caolanm 2008-01-23 14:22:14 UTC
export SAL_ENABLE_CAIROTEXT=1 to enable it, emboldening disabled for now.
Comment 18 moxfox 2008-01-24 20:09:18 UTC
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? 
Comment 19 hdu@apache.org 2008-01-25 08:11:39 UTC
@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.
Comment 20 moxfox 2008-01-26 11:55:02 UTC
@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.
Comment 21 caolanm 2008-01-28 15:12:49 UTC
done in cairotext01
Comment 22 caolanm 2008-01-30 08:56:32 UTC
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.
Comment 23 hdu@apache.org 2008-01-30 09:12:57 UTC
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.
Comment 24 hdu@apache.org 2008-01-30 09:21:31 UTC
@cmc: Oops, I hadn't noticed that the CWS already had its status changed. Sorry for checking something 
in after that.
Comment 25 stefan.baltzer 2008-02-20 15:43:02 UTC
Reassigned to me (ES on vacation).
Comment 26 stefan.baltzer 2008-02-26 10:53:20 UTC
Verified in CWS cairotext01.
Comment 27 hdu@apache.org 2008-08-05 14:43:29 UTC
*** Issue 3886 has been marked as a duplicate of this issue. ***
Comment 28 thorsten.ziehm 2009-07-20 15:56:54 UTC
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