[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New release of libart/freetype-backend
New release of libart/freetype-backend
Tue, 30 Apr 2002 00:56:29 +0200
I've decided that it's time to do another public release of my
It's a bit ugly and I'm going to rewrite and clean up now, so I thought
it'd be good to release a functional version first. The instructions in
the previous mail still apply:
Extract it in core/back/, apply the patch, run autoconf, fix the paths
in core/back/Source/art/GNUmakefile.preamble (and possibly the libraries
in core/back/Source/GNUmakefile.preamble), run './configure
--enable-art'. Requires recent versions of libart and freetype.
It now uses XShm (if available), and is quite fast. It 'feels' at least
as fast as xgps, but I haven't used xgps in a while so it's getting hard
for me to tell :).
AFAICT, all DPS* operators in NSGraphicsContext.h are now implemented
Shouldn't be that hard, quite similar to compositeGState:...
Should be implemented in gsc. I'll probably get around to it soon.
ashow, widthshow, awidthshow, xshow, yshow, xyshow
Easy, but I want to clean the code up first to avoid excessive code
A bit tricky, but it should be possible. Requires a fair amount of work
to cover all the stuff that needs to be clipped, though.
aren't implemented since I don't know what they're supposed to do. None
of the other backends implement them, and gui never uses them. Why do
Is currently very limited, but it handles what NSImage tries to do.
Transforms work properly in most cases, including transformed text
Charpath works (backartf.png). Scaling of line widths and dash patterns
doesn't work properly.
A few DPS-related questions:
Arcs aren't handled properly currently. The arc needs to created in user
space and then transformed to device space. The gsc code (tries to)
transform the center and radius and makes a circular arc in device
space. My code currently builds the entire path in user space and
transforms when drawing, so elliptical arcs are possible, but this means
that switching the ctm during during path building/drawing isn't handled
-gui doesn't seem to use strokeadjust. Should it? I already fudge
coordinates slightly in some cases. A lot of width 1 rectstroke:s appear
at whole points (eg. (10,10)-(20,20)), which means that the bottom
border appears as a filled area (10,9.5)-(20,10.5), which is rendered as
50% fill in row 9 and 10. I detect this and adjust the coordinates to
prevent it. Technically, I should probably only do this (and some other
related adjustments) if strokeadjust is active, but then gui would need
to use it.
What exactly am I supposed to do about view flipping? Does it belong in
the backend at all? Currently I just flip the y axis when drawing text
if viewIsFlipped is YES, and this seems to work.
How sophisticated should my font rendering be? Should I do kerning and
stuff in DPSshow:?
To get good unicode coverage with all fonts, I've implemented a simple
fallback-font scheme. If a glyph can't be found for a character in the
current font, it will try to find it in the global fallback font and
render that instead. I'm considering extending this, but I'm not sure
it's the right thing to do. Should the backend try to always find a
glyph for a character (with different fallback fonts for different fonts
and stuff like that), or should it leave all that to -gui?
To test various DPS features I wrote a quick DPSTest.app (heavily based
It probably isn't very intuitive to use, but I've found it very useful.
Basically, tests with a 'Draw' button actually render something to the
window, and tests that are 'Active' modify the gstate in some way before
each draw (current color, dash pattern, ctm, path,...). Everything
should run (though not necessarily with correct results) with xgps
except the path analyzer (uses a backart specific method to get the
current path) and 'Activate' in the Text-test (uses charpath).
- Alexander Malmberg
- New release of libart/freetype-backend,
Alexander Malmberg <=