Clemens Eisserer wrote: > Hello, > > I am the student who submitted the proposal about implementing > subpixel-font-smoothing in OpenOffice's font rendering system. > > I am not very familiar with OpenOffice's source-code, what could be > specific challenges?
First challenge is to get the build system to work on your system. I hope this is fairly straightforward nowadays. Please have a look at http://development.openoffice.org for a general overview and http://tools.openoffice.org/build_env.html for an overview of how to build the code. Our build system sadly is a tad more complicated to use than most projects. > I thought about it and this are the challenges I would see: > > - Problem with XOR painting (selection, cursor, ...). Currently even > AcrobatReader suffers from this, and selected text suffers from > colored pixels on the glyph outlines. > Now that XRender is widely supported (and hw implementations are very > slowly arriving now, maybe selection could be done using painting with > apha? Using an alpha rectangle for selections is already in progress, so that will not be a problem at some point. In controls (like e.g. Edit fields) it is not a problem anyway since the selection is not done by XOR but by drawing the selection color and then text above it. > - Performance: > Subpixel-smoothing can't be done on hardware, however XRender has as > far as I know an API which would allow accaleration by the driver. No > idea a about windows, I am just afraid rendering to vram-surfaces and > reading back could be too inefficient :-/ You don't need to handle Windows at all, it does that automatically for text. However you seem to be talking about more than fonts now. HDU already is working on subpixel rendering for polygons in our effort for drawing primitives, maybe he'll drop a line about that ? > - Maybe OpenGL accalerated rendering: > Maybe we could hook the complete drawing on top of some abstraction > layer (cairo or Java2d-native-backends when freed). My favourite would > be really Java2D, I hope it'll get some useful native C-bindings (not > going the native->jni->jvm->jni->native way). > As far as I know this stuff is already implemented there very > efficiently - and we could support several backends like OpenGL, D3D, We do that for the presentation with the canvas implementaion; there is one based on Cairo, one based on vcl and some others. OpenGL was a plan, but OpenGL on Linux is not something you can use everywhere. > However I guess even the bindings would be enough for a seperate SoC > proposal ;) Indeed ;-). I think having subpixel rendering for fonts going will be a very good thing; if there is time left (and you still want to ;-) ) you can go on to other areas. Kind regards, pl -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
