RSS Feed
Bookmark to Delicious
Wednesday, 26 Aug 2009
accessibility
api
architecture
automated_tests
base
beta
build
calc
candidate
chart
code
community
database
development
directx
document
download
draw
eis
events
export
extensions
features
filter
framework
graphics
gsl
gsoc
gullfoss
import
impress
installation
iso26300
java
l10n
localization
mac
netbeans
odf
ooo
ooocon
ooocon2008
ooocon2009
open
open-source
opendocument
openoffice
openoffice.org
opensource
pdf
performance
porting
qa
quality
quaste
release
renaissance
security
snapshot
software
specification
spreadsheet
staroffice
statistics
sun
survey
testing
toolkit
tools
usability
user-experience
video
web
wiki
writer
xml
- show all articles
Wednesday, 26 Aug 2009
Herbert Duerr
OpenOffice.org already has over a hundred localizations. Its internationalization core does this by integrating with the system's text shaping engines such as ATSUI on OSX, Uniscribe on Windows and ICU for the X11 based platform targets. With OpenOffice.org's latest developer milestone DEV300_m56 it also got support for Graphite's “smart font features”. Graphite becomes active when a font is selected that has been specially
designed for the graphite engine. The idea behind graphite is that the code only has to handle the I18N aspect of text layout and its fonts provide all the L10N details. People whose scripting systems are not yet supported by the normal shaping engines can now enjoy the power of OpenOffice.org just by installing some fonts.
OpenOffice.org's support for Graphite works great for formatting, printing and for exporting as PDF. As the user interface for selecting non-default font features and styles is not defined yet (#i16032#) many things made possible by the new feature can currently only be selected by creating and using special style sheets or hardcoded font names. Document import/export is also working on improving support in this area (#i79878#). Any improvements on these frontiers should and will be dealt with in a backwards compatible way, so any document using the new feature will also look good in the future.
There are some more caveats, e.g. the new feature “graphite support” is currently only enabled on Linux and Windows. Other platforms will be enabled later. It turns out that using an external project library which relies on templates such as STL are not as easy to integrate as one would wish. Getting it all into such a state that everything works fine independent on whether it has been compiled in the plain Ooo- or in the HH-RE build environment, for product- or debug-enabled builds and with OOo-internal or system stlport and for every targeted platform was quite difficult.
Getting graphite support into core OpenOffice.org
builds was made possible by the work of Keith Stribley and Tim Eves.
Many thanks to them!
Speaking of progress in the development of OpenOffice.org I'd also like to mention that one of the features with the highest vote counts has just been implemented (#i43029#) in my ChildWorkSpace named "otf01". I'll blog more about that soon when the feature becomes available in one of the next development milestones for the OOo 3.2 code line. With all the users of minority scripts rejoicing now many more users will have reason to rejoice soon.
tags: i18n l10n openoffice.org
Digg this
Comments
Wikipedia says ATSUI has been replaced with Core Text with Leopard.
What does that mean?
Posted by Sven on August 26, 2009 at 07:15 PM CEST #
From OSX 8.5 to 10.4 ATSUI was the API for advanced text shaping on OSX. It mainly supported AAT-enhanced ("Apple-Enhanced-Typography") fonts. The competing OpenType clearly dominates the market since a while though, so Apple gradually phased in OpenType support into newer versions OSX. IMHO it would have been possible to do it transparently by just keeping the ATSUI API, but they decided to start over, deprecate the API that was up to OSX 10.4 en vogue and replace it with a new one.
What does it mean for OOo users on Mac? As long as we have the minimum requirement for our OSX platform on 10.4 we will support ATSUI on OOo Aqua. We will phase in support for CoreText gradually, maybe for OOo 3.3 (depending on other priorities).
Hope that helps. Are there any particular problems with ATSUI that everyone is unhappy with? How could anyone live with these problems before OSX 10.5?
Posted by hdu on August 27, 2009 at 01:25 AM CEST #
Oh, I got the irony :D
I'm just curious. Font rendering in OOo is painfully slow - try a two-finger scroll in a page full of text with Pages and Writer. Pages runs extremely smooth, but Writer flickers like it's 1999. On a 2,5 GHz dual core machine with 4 GB of memory.
I admit i'm not aware of any technical reasons behind this.
Posted by Sven on August 27, 2009 at 02:58 PM CEST #
The font rendering is quite fast. It's the Writer interacting with OOoAqua's window scrolling that needs get a few tweaks. Currently there is still way too much unneeded copying from/to graphics memory to main memory and back in OOo. Getting everything to work right was the main priority. When this is done and the hot code paths are identified then the canonical implementations can often be replaced by much faster dedicated counterparts. It is all a matter of priorities though. Is a faster scroll more important than using CoreText, 64bit support, more OpenType features, smaller PDFs, better interoperability, more system integration, better support for more localizations, etc.? Would the solution for faster scrolling even be noticeable in the next hardware generation? Or in the next OS major release or even minor release?
Posted by hdu on August 27, 2009 at 03:48 PM CEST #
Since you provoked - here is my humble opinion :)
Most important thing is seamless workflow.
It is NOT the feature checklist (it is good actually), but the sum of small details, so that software becomes invisible. Yes, invisible. Not a window with buttons, but like a good handtool, extension to your fingers.
I think good system integration and well thought-out UI is what moves general purporse software towards the goal of becoming invisible.
Currently OOo is the only software in my system that flickers screen and uses awkward multi-layered tabs in toolboxes. I understand that reorganising UI is enormous work, much bigger than adding features one by one or fixing bugs, therefore I don't complain.
But still - eliminating existing distractions would be much preferable to adding new features.
Posted by Sven on August 27, 2009 at 04:36 PM CEST #