On 05.10.2005 09:46:18 Manuel Mall wrote:
> While I am at it (this whole alignment stuff I mean) we may as well do
> it properly. This would include support for the "script" property. The
> allowed values for script are defined for example here:
> http://www.unicode.org/iso15924/iso15924-codes.html.
> 
> I assume we don't bother to validate if a correct code has been
> provided as we don't do that for the "country" and "language"
> properties either (should we? If we do we need more external config
> files or expand fop.xconf to hold those values as they tend to change
> over time).

We don't have to but we could. Since this is not something that changes
often I wouldn't put it into the config file, but in resource files
instead.

> But what we do need is a mapping from scripts to default baselines for
> these scripts. I haven't found a mapping list on the net. Any one come
> across something like that?

Nope.

> Otherwise we may have to make that up. That
> means entries somewhere similar to: <script code="Guru"
> baseline="hanging" />. Is the fop config file the right place for this
> stuff?

Again, I'd put it in separate resource files as this is not going to
change often and a rebuild of FOP is not the end of the world in this
case.

> Any not defined scripts encountered in an fo file would map to
> baseline="alphabetic" (may be with a warning to the user?).

Sure.

> What we also need for proper script support is a mapping from Unicode
> code point to script. The mappings are for example defined here:
> http://www.unicode.org/Public/UNIDATA/Scripts.txt.
> How would one best process this? 

<shrug/>

> (has this been done in FOP before?)

I don't think so.

> Is there other Unicode stuff FOP needs which should be considered at the 
> same time? 
> Are we better off working with the "raw" Unicode data 
> (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)?

<shrug/>

We should simply make sure that this doesn't influence performance too
much for the big majority of users happy to use latin scripts. After all,
this looks like many lookups are necessary and all these maps have to be
loaded at one point.


Jeremias Maerki

Reply via email to