Optional OpenType features

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Optional OpenType features

Miloš Hadžić
Hello,

I would like to work on support for optional OpenType features as my
internship project.

I did not see it on the list of suggested projects. Is it because it
is not a priority feature?

I know that currently OpenOffice has support for Graphite, and some of
the advanced typographical features like ligatures work with
Graphite-enabled fonts such as those that are made by SIL. There is
also an extension[1] which should enable optionality for those fonts
but it did not really work when I tried it.

I would like to work on enabling these features for all OpenType fonts
that support them.

Is anyone working on this right now?

Kind regards,
Milos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
Hi Miloš,

On Jun 16, 2010, at 6:05 PM, Miloš Hadžić wrote:
> I would like to work on support for optional OpenType features as my
> internship project.

That is quite an ambitious plan, especially with issues such as  
#i79879# still being open.

Adding support for optional OpenType features is related but requires  
much more work:
- there needs to be an UI for selecting which features to apply  
(#i16032#)
- the document-spec needs to be enhanced to support them
- the document importers and exporters need to be updated accordingly
- the layout engines need to support them (e.g. ICU or Uniscribe's  
public API only allow very few optional features e.g. GPOS-kerning)
- the application layer codes in the WriterEngine and EditEngine need  
to be updated not to override layout engine results with their  
simplistic view of things (#i108684#)

> I did not see it on the list of suggested projects. Is it because it  
> is not a priority feature?

Good question. Having important customers request such features would  
certainly help to give the wish a higher priority.

> I know that currently OpenOffice has support for Graphite, and some of
> the advanced typographical features like ligatures work with
> Graphite-enabled fonts such as those that are made by SIL. There is
> also an extension[1] which should enable optionality for those fonts
> but it did not really work when I tried it.
>
> I would like to work on enabling these features for all OpenType fonts
> that support them.
>
> Is anyone working on this right now?


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.

A related topic for all platforms is GPOS-kerning (#i31764#): In one  
way is simpler, because the UI, the document-spec and application  
layer support is already there, in the other way it is also very  
challenging because the layout of existing document must not change  
(e.g. because a font only has classic kerning and a layout engine only  
supports GPOS kerning or because the layout depends on the feature  
"CJK kerning").

---
Herbert Duerr
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Miloš Hadžić
Hi Herbert,

On Thu, Jun 17, 2010 at 08:40, Herbert Duerr <[hidden email]> wrote:
> Hi Miloš,
> That is quite an ambitious plan, especially with issues such as #i79879#
> still being open.

Is that issue number correct?

> Adding support for optional OpenType features is related but requires much
> more work:
> - there needs to be an UI for selecting which features to apply (#i16032#)
> - the document-spec needs to be enhanced to support them
> - the document importers and exporters need to be updated accordingly
> - the layout engines need to support them (e.g. ICU or Uniscribe's public
> API only allow very few optional features e.g. GPOS-kerning)
> - the application layer codes in the WriterEngine and EditEngine need to be
> updated not to override layout engine results with their simplistic view of
> things (#i108684#)

That does sound like a lot of work. Not that I wouldn't want to do it,
but I'm not sure how much of it I would be able to complete in 3
months.

>> I did not see it on the list of suggested projects. Is it because it is
>> not a priority feature?
>
> Good question. Having important customers request such features would
> certainly help to give the wish a higher priority.

Maybe more people will request it now that it is well supported in Word 2010.

> 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?

> A related topic for all platforms is GPOS-kerning (#i31764#): In one way is
> simpler, because the UI, the document-spec and application layer support is
> already there, in the other way it is also very challenging because the
> layout of existing document must not change (e.g. because a font only has
> classic kerning and a layout engine only supports GPOS kerning or because
> the layout depends on the feature "CJK kerning").

I suppose that if the engine supported both it could have plain
kerning as default if the font has it. Some of the newer fonts come
with only GPOS kerning and the engine would use that. Could something
like that work?

This is something I would like to work on. I really like typography
and would like to see better support for it in OOo.

Kind regards,
Miloš

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
Hi Miloš,

>> That is quite an ambitious plan, especially with issues such as  
>> #i79879#
>> still being open.
>
> Is that issue number correct?

Yes, the application layers, document import+export, etc. all have  
problem when a font has more than four styles available. The optional  
typographic features can be considered as style-multipliers...

>
>> Adding support for optional OpenType features is related but  
>> requires much
>> more work: [...]
>
> That does sound like a lot of work. Not that I wouldn't want to do it,
> but I'm not sure how much of it I would be able to complete in 3
> months.

I agree with that.

>>> I did not see it on the list of suggested projects. Is it because  
>>> it is
>>> not a priority feature?
>>
>> Good question. Having important customers request such features would
>> certainly help to give the wish a higher priority.
>
> Maybe more people will request it now that it is well supported in  
> Word 2010.

Probably.

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.

>> 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#.

>> A related topic for all platforms is GPOS-kerning (#i31764#): In  
>> one way is
>> simpler, because the UI, the document-spec and application layer  
>> support is
>> already there, in the other way it is also very challenging because  
>> the
>> layout of existing document must not change (e.g. because a font  
>> only has
>> classic kerning and a layout engine only supports GPOS kerning or  
>> because
>> the layout depends on the feature "CJK kerning").
>
> I suppose that if the engine supported both it could have plain
> kerning as default if the font has it. Some of the newer fonts come
> with only GPOS kerning and the engine would use that. Could something
> like that work?

Yes, that is the plan how it will look to the upper layers. Whether  
the system layout engines do it this way too reliably is the other  
question.

> 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?

---
Herbert Duerr
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

David Tardon
On Thu, Jun 17, 2010 at 04:45:55PM +0200, Herbert Duerr wrote:

> Hi Miloš,
>
> >>That is quite an ambitious plan, especially with issues such as
> >>#i79879#
> >>still being open.
> >
> >Is that issue number correct?
>
> Yes, the application layers, document import+export, etc. all have
> problem when a font has more than four styles available. The
> optional typographic features can be considered as
> style-multipliers...
>

Hi, Herbert,

I suppose you really meant #i79878#?

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
>>>> That is quite an ambitious plan, especially with issues such as
>>>> #i79879# still being open.
>>>
>>> Is that issue number correct?
>>
>> [...]
>
> I suppose you really meant #i79878#?


Yes, thanks!

---
Herbert Duerr
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Miloš Hadžić
In reply to this post by Herbert Duerr
Hi Herbert,

On Thu, Jun 17, 2010 at 16:45, Herbert Duerr <[hidden email]> wrote:
> Probably.
>
> 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.

>>> 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.

>>> A related topic for all platforms is GPOS-kerning (#i31764#): In one way
>>> is
>>> simpler, because the UI, the document-spec and application layer support
>>> is
>>> already there, in the other way it is also very challenging because the
>>> layout of existing document must not change (e.g. because a font only has
>>> classic kerning and a layout engine only supports GPOS kerning or because
>>> the layout depends on the feature "CJK kerning").
>>
>> I suppose that if the engine supported both it could have plain
>> kerning as default if the font has it. Some of the newer fonts come
>> with only GPOS kerning and the engine would use that. Could something
>> like that work?
>
> Yes, that is the plan how it will look to the upper layers. Whether the
> system layout engines do it this way too reliably is the other question.
>
>> 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 moth internship?

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.

Regards,
Miloš

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
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
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Miloš Hadžić
Hi Herbert,

First of all, sorry for replying with a delay, I'm finishing my end of
semester exams.

>>>>> 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.

It feels like solving one of these issues leads to two more problems
appearing. That makes this project hard to define in hard bounds and
me hesitant to take on too much responsibility for the duration of the
internship. I'd like to continue contributing but will almost
certainly be unable to do so full time due to school obligations. So
in a way I agree that this project is not an ideal one for a three
month internship. The ones on the project proposals page are much
better defined and straightforward. That said, I'd still like the
opportunity to do it. Even if it would indeed be better to do it one
step at the time, as you said, I think I could make quite a bit of
progress in bringing this feature to a stable state.

So I would propose that:

- I finish #i112466# and implement a way to test it in the application
layer(for example in the manner that you described)
- Fix any issues that arise from it

If I finish this early, and I expect to do so, continue to work on #i79878#.

I intend to document what I do extensively which should help anyone
writing new code with mine in mind.

Kind regards,
Miloš

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
Hi Miloš,

> It feels like solving one of these issues leads to two more problems
> appearing. That makes this project hard to define in hard bounds

Exactly.

> and me hesitant to take on too much responsibility for the duration  
> of the
> internship. I'd like to continue contributing but will almost
> certainly be unable to do so full time due to school obligations. So
> in a way I agree that this project is not an ideal one for a three
> month internship. The ones on the project proposals page are much
> better defined and straightforward. That said, I'd still like the
> opportunity to do it. Even if it would indeed be better to do it one
> step at the time, as you said, I think I could make quite a bit of
> progress in bringing this feature to a stable state.
>
> So I would propose that:
>
> - I finish #i112466# and implement a way to test it in the application
> layer(for example in the manner that you described)
> - Fix any issues that arise from it

Sounds good.

> If I finish this early, and I expect to do so, continue to work on  
> #i79878#.

It would be really great if this issue was solved for good.

> I intend to document what I do extensively which should help anyone
> writing new code with mine in mind.


I'm looking into making that internship happen because you seem to be  
quite competent and self-motivated. I'm discussing this with the  
writer team as the #i112466# part of the project would be mentored by  
me, the #i79878# part by someone from the writer team. Not sure how  
this works out with vacation plans etc. Stay tuned...

---
Herbert Duerr
[hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Mathias Bauer
On 23.06.2010 10:44, Herbert Duerr wrote:

> I'm looking into making that internship happen because you seem to be
> quite competent and self-motivated. I'm discussing this with the writer
> team as the #i112466# part of the project would be mentored by me, the
> #i79878# part by someone from the writer team. Not sure how this works
> out with vacation plans etc. Stay tuned...

We can't discuss that without Oliver Specht (the owner of #i79878) who
will not be available before tomorrow. So at the moment I can give just
some general comments as a member of the Internship committee.

IMHO working on these issues can be part of the Internship program, even
if it is hard to draw an exact boundary where and when the project will
end. I would be fine with finding an agreement about that while the work
is done. Also interruptions of the work due to other duties would be
fine for me if that happens in a calculable manner.

Some words about issue #79878: this will require working on UI code as
well as on application core code (new items etc.). I assume that also
VCL will be affected. So all in all that will be a lot of code to get
familiar with. Miloš, if you want to take that challenge, I will try to
find a mentor (or several of them) for the work outside of VCL.

Best regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Miloš Hadžić
>> I'm looking into making that internship happen because you seem to be
>> quite competent and self-motivated. I'm discussing this with the writer
>> team as the #i112466# part of the project would be mentored by me, the
>> #i79878# part by someone from the writer team. Not sure how this works
>> out with vacation plans etc. Stay tuned...
>
> We can't discuss that without Oliver Specht (the owner of #i79878) who will
> not be available before tomorrow. So at the moment I can give just some
> general comments as a member of the Internship committee.
>
> IMHO working on these issues can be part of the Internship program, even if
> it is hard to draw an exact boundary where and when the project will end. I
> would be fine with finding an agreement about that while the work is done.
> Also interruptions of the work due to other duties would be fine for me if
> that happens in a calculable manner.
>
> Some words about issue #79878: this will require working on UI code as well
> as on application core code (new items etc.). I assume that also VCL will be
> affected. So all in all that will be a lot of code to get familiar with.
> Miloš, if you want to take that challenge, I will try to find a mentor (or
> several of them) for the work outside of VCL.

I would be happy to take that challenge.

I couldn't find a timeline for the internship on the site. When would
I formally start(should I get accepted)? July 1st?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Cor Nouws
Hi Miloš,

Miloš Hadžić wrote (23-06-10 16:44)
>
> I couldn't find a timeline for the internship on the site. When would
> I formally start(should I get accepted)? July 1st?

Info can be found here:
http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship

Regards,
Cor


--
  >> Your office 2010 software: the new OpenOffice.org <<

Cor Nouws
   - ideas/remarks for the community council?
   - http://wiki.services.openoffice.org/wiki/Community_Council


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Mathias Bauer
In reply to this post by Mathias Bauer
On 06/23/2010 11:51 AM, Mathias Bauer wrote:

> On 23.06.2010 10:44, Herbert Duerr wrote:
>
>> I'm looking into making that internship happen because you seem to be
>> quite competent and self-motivated. I'm discussing this with the writer
>> team as the #i112466# part of the project would be mentored by me, the
>> #i79878# part by someone from the writer team. Not sure how this works
>> out with vacation plans etc. Stay tuned...
>
> We can't discuss that without Oliver Specht (the owner of #i79878) who
> will not be available before tomorrow. So at the moment I can give just
> some general comments as a member of the Internship committee.
>
> IMHO working on these issues can be part of the Internship program, even
> if it is hard to draw an exact boundary where and when the project will
> end. I would be fine with finding an agreement about that while the work
> is done. Also interruptions of the work due to other duties would be
> fine for me if that happens in a calculable manner.
>
> Some words about issue #79878: this will require working on UI code as
> well as on application core code (new items etc.). I assume that also
> VCL will be affected. So all in all that will be a lot of code to get
> familiar with. Miloš, if you want to take that challenge, I will try to
> find a mentor (or several of them) for the work outside of VCL.

Meanwhile I discovered a serious problem that might let us postpone this
work. Whatever users select in the dialog, it must be stored in the
document. For several reasons it's not enough to just store the complete
font name (and let the program fiddle out the details when the document
is loaded again), we also must store the font properties as text
attributes. As ODF currently does not support all that we need, it seems
that a file format change is necessary. That's not impossible, but will
take some time, especially as the ODF TC is still busy with finishing
ODF 1.2.

So at least we have to make a plan for the file format changes before we
can discuss the details of when and how issue #78978 can be fixed.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Miloš Hadžić
On Thu, Jun 24, 2010 at 16:30, Mathias Bauer <[hidden email]> wrote:

> On 06/23/2010 11:51 AM, Mathias Bauer wrote:
>>
>> On 23.06.2010 10:44, Herbert Duerr wrote:
>>
>>> I'm looking into making that internship happen because you seem to be
>>> quite competent and self-motivated. I'm discussing this with the writer
>>> team as the #i112466# part of the project would be mentored by me, the
>>> #i79878# part by someone from the writer team. Not sure how this works
>>> out with vacation plans etc. Stay tuned...
>>
>> We can't discuss that without Oliver Specht (the owner of #i79878) who
>> will not be available before tomorrow. So at the moment I can give just
>> some general comments as a member of the Internship committee.
>>
>> IMHO working on these issues can be part of the Internship program, even
>> if it is hard to draw an exact boundary where and when the project will
>> end. I would be fine with finding an agreement about that while the work
>> is done. Also interruptions of the work due to other duties would be
>> fine for me if that happens in a calculable manner.
>>
>> Some words about issue #79878: this will require working on UI code as
>> well as on application core code (new items etc.). I assume that also
>> VCL will be affected. So all in all that will be a lot of code to get
>> familiar with. Miloš, if you want to take that challenge, I will try to
>> find a mentor (or several of them) for the work outside of VCL.
>
> Meanwhile I discovered a serious problem that might let us postpone this
> work. Whatever users select in the dialog, it must be stored in the
> document. For several reasons it's not enough to just store the complete
> font name (and let the program fiddle out the details when the document is
> loaded again), we also must store the font properties as text attributes. As
> ODF currently does not support all that we need, it seems that a file format
> change is necessary. That's not impossible, but will take some time,
> especially as the ODF TC is still busy with finishing ODF 1.2.
>
> So at least we have to make a plan for the file format changes before we can
> discuss the details of when and how issue #78978 can be fixed.

That really is unfortunate. If I understood your email right,
additions to the file format will take longer than a few months to
complete?

Then I could still work on #i112466# and when that is finished, see
what would be the next priority. For example #i108684#.

Kind regards,
Miloš

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Mathias Bauer
On 06/25/2010 01:14 PM, Miloš Hadžić wrote:

> On Thu, Jun 24, 2010 at 16:30, Mathias Bauer<[hidden email]>  wrote:
>>
>> Meanwhile I discovered a serious problem that might let us postpone this
>> work. Whatever users select in the dialog, it must be stored in the
>> document. For several reasons it's not enough to just store the complete
>> font name (and let the program fiddle out the details when the document is
>> loaded again), we also must store the font properties as text attributes. As
>> ODF currently does not support all that we need, it seems that a file format
>> change is necessary. That's not impossible, but will take some time,
>> especially as the ODF TC is still busy with finishing ODF 1.2.
>>
>> So at least we have to make a plan for the file format changes before we can
>> discuss the details of when and how issue #78978 can be fixed.
>
> That really is unfortunate. If I understood your email right,
> additions to the file format will take longer than a few months to
> complete?
>
> Then I could still work on #i112466# and when that is finished, see
> what would be the next priority. For example #i108684#.

As no work has started on the file format issues, it's unpredictable how
long it may take. Usually we start to implement things in OOo when the
ODF TC has agreed on a specification for the feature; it won't be
necessary that the feature will be already in the published standard. So
*if* we could start the discussion about the extensions we need for
better font face support right now, and *if* the agreement in the TC
could be achieved pretty fast, we could be finished in a few days. But
there are the two "if"...

I leave it up to the gsl team to answer your question about #i108584.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional OpenType features

Herbert Duerr
>>> So at least we have to make a plan for the file format changes  
>>> before we can
>>> discuss the details of when and how issue #78978 can be fixed.
>>
>> That really is unfortunate. If I understood your email right,
>> additions to the file format will take longer than a few months to
>> complete?
>>
>> Then I could still work on #i112466# and when that is finished, see
>> what would be the next priority. For example #i108684#.
>
> As no work has started on the file format issues, it's unpredictable  
> how long it may take. Usually we start to implement things in OOo  
> when the ODF TC has agreed on a specification for the feature; it  
> won't be necessary that the feature will be already in the published  
> standard. So *if* we could start the discussion about the extensions  
> we need for better font face support right now, and *if* the  
> agreement in the TC could be achieved pretty fast, we could be  
> finished in a few days. But there are the two "if"...

We're lucky that the ODF standard is quite related to other standards  
such as SVG, CSS, etc. were some of the sorely missing properties are  
already defined (such as the "font-stretch" property), so that the  
process to add them should be quite simple and predictable.

For solving the worst problems of #i78978# these properties would  
suffice and if the code that forgets these properties today was fixed  
well extending it to handle the remaining properties (that are still  
in progress for CSS3) would be much easier.

CSS3's "font-variant" property points into the right direction how the  
optional opentype features could be handled. Example: "font-
variant:small-caps" maps well to the OT feature "smcp".
The discussions on CSS mailing list indicate that the other features  
will likely be supported in a similar way.

> I leave it up to the gsl team to answer your question about #i108584.


Solving #i108684# would be a very worthwhile goal. Most of the code  
changes would be in WriterEngine/EditEngine though, where
- their calls to DrawTextArray() calls would only provide targetwidths  
instead of dxarrays
- they would get the cursor positions from GetCaretPositions() instead  
of guessing them

---
Herbert Duerr
[hidden email]

Sun Microsystems GmbH
Sonnenallee 1
D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Jürgen Kunz

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]