Hi Miloš,
Topics that everybody yawned at more than once got the priority "we
needed
that yesterday"! On the other hand I also saw
http://fontfeed.com/archives/ipad-typography/ where it shows that
top-notch
typography is not a requirement even for the most successful
appliance used
by many graphic designers, artists and other creative people that
usually
have good style as a major goal.
That is a good example of typography getting the back seat treatment
which has sadly become the norm. It is encouraging to see that
Windows, OS X and Linux either have or are working on high quality
text APIs.
I agree with that.
With OOo's Aqua port moving from ATSU to CoreText and CoreText
supporting
optional typographic features the Aqua port is likely to be the
spearhead
of this effort.
That is interesting. Are there plans to use DirectWrite in the
Windows
version?
Not yet. On Windows the next typography step is probably doing issue
#i112466#.
I don't yet know how OOo renderrs text in detail but I believe that it
would be possible and not too complicated to use DirectWrite/Direct2D
just for rendering.
Using the Win7 specific DirectWrite API would have some benefits, but
because of #i108684# (WriterEngine and EditEngine having problematic
assumptions about the best division of responsibility between layers)
the benefits would be quite overshadowed by these problems. Until they
are solved they would also introduce some regressions which are
currently only seen on the Aqua port (such as cursor traveling in
justified text).
This is something I would like to work on. I really like typography
and would like to see better support for it in OOo.
Good! Could I interest you in working in the WriterEngine and
EditEngine on
#i108684#?
Or are you more into system-level code? What is your prefered
platform? WIN,
UNX or MAC?
If WIN could I interest you in #i112466#?
If UNX could I interest you in providing the optional features
through ICU?
I'd like to take on #i112466#. Would that be appropriate in scope for
a 3 month internship?
The effect that the optional features would provide would be invisible
as long as the wiring in the app-layers is not there yet. So most of
the resulting problems would be invisible too... I'm not sure if
implementing just #i112466# would fill a 3-month internship.
Maybe if we extended the scope by doing it as an experimental feature,
e.g. by using the style-name of the font request such as in
"Book:cpsp:liga:frac:zero", which would allow to test it on the
application level. The most obvious problem would be #i79878#, but I
am worried about the many seemingly minor problems such as layout
instabilities e.g. when font attributes change within a line. Or when
the printer substitutes fonts behind our back. They seem minor at
first but when documents start to depend on it the headaches begin.
Finding all these subtle problems (to prevent headaches in the future)
and also addressing such questions as what to do on systems where the
APIs are not available (such as XP) would be a lot of work. I wanted
to start it when switching from the ATSUI API to CoreText.
The question what to do if a platform does not support the APIs or the
available font does not support a requested feature could in some
cases be handled by emulating features such as "sinf/subs/sups". These
could be tested by adjusting Math.
So I'm not sure on how to outsource this into a three month slot. I'm
convinced the only way to do all this is by doing one step after the
other and taking responsibility for design decisions by solving all
subsequent issues.
Before my original mail here I read about HarfBuzz which is probably
what someone working on providing OT features on linux through ICU
should use but I'm not sure if the APIs are finalized.
Currently OOo uses platform specific glyph layout engines, as the
shapers on OSX and WIN are still so much better especially for
justified text and drawing layouted results requires their layout
objects. OOo implements a layer on top of them to emulate what is
expected by the app-layers (#i108684# again). And e.g. ICU doesn't
bother with text justification at all. If the platform specific
engines lose their lead over the open-source engines then we will
probably settle on one open source engine. Harfbuzz has good chances
win this race. With OSX's CoreText being quite similar to its API the
step from CT->HB should be simple.
---
Herbert Duerr
du...@sun.com
Registered Office: Sun Microsystems GmbH
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Jürgen Kunz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
For additional commands, e-mail: dev-h...@gsl.openoffice.org
