Re: Java text geometry

[Christian Z.]

Hi Simon!

> ExTeX, isn't that the name devised for NTS, but never used? Who are
> using that now? Is there development in that area?

Yes, it is. I saw you wrote a note about it some years ago. You can find
the project homepage under http://www.dante.de/projects/extex/. Although
the website seems to be quiet a bit, they're currently putting their
source code to a public CVS server. I think they started active
development last year, but I'm not sure about that.


Christian Z.

Re: Java text geometry

[Simon Pepping]

Christian,

On Tue, Jun 29, 2004 at 07:58:41PM +, Christian Z. wrote:
> Hi Peter!
> 
> else. So, just ask, if there are questions. Furthermore I'm currently
> talking to the ExTeX people. IMO ExTeX will be _very_ similar to FOP in
> the end effect, but currently has different priorities. And of course it
> will be based on TeX in some kind not XSL. Cause they want to eliminate
> TeX's drawbacks (including multilingual text) it perhaps makes sense to
> get in touch with them too. BTW: They would like to use the Batik code
> for reading TTF-files. I think there are Batik members here too? Perhaps
> one of you could drop them a line...

ExTeX, isn't that the name devised for NTS, but never used? Who are
using that now? Is there development in that area?
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Java text geometry

[Christian Z.]

Hi Peter!

> Sorry it's taken me so long to get back to you on this.  What's UTA?

UTA (Unified Typesetting API) is my attempt to provide an API for
typesetting that can be used by all kinds of text processing
applications. The primary goals are
* the ability that support for new scripts can easily be added
* support for low and high quality implementations of the API

Currently UTA provides an API for line-breaking similar to TeX's
mechanism (also TeX's behavior should be a special case of my model)
which I think is quite stable and will change only little till the
Milestone 1 release anytime around 9/1/2004. It also provides an
implementation of the simple-fit line-breaking algorithm as proof of
concept. There's also a helper package to allow global optimizing
line-break algorithms using a BSD licensed graph theory package (only
found a forrest report about an apache graph library without further
information, Jeremias). This package may be irrelevant in future
releases and is not needed to use the API. Furthermore there's the API
of how I think multilingual text can be set. This is subject to change,
I'll have to refactor/cleanup a bit and add some ideas.

Note that the code currently reflects my knowledge and therefore is
subject to change and perhaps will not fulfill all future requirements
right now. Note also that my focus currently only lies on the task to
define an API on how to typeset multilingual glyphs and how to break a
paragraph into lines. I can't currently provide implementations for
typesetting nor for advanced line-breaking algorithms.

UTA addresses some of FOP's low priority tasks and I think the task
you're currently working on. I had to take a look into the problems of
multilingual typesetting, TeX, XSL, the Java API, Pango, ATSUI,... I do
not claim to know everything about all of this technologies but I think
I can be of use for you providing you with further reading or something
else. So, just ask, if there are questions. Furthermore I'm currently
talking to the ExTeX people. IMO ExTeX will be _very_ similar to FOP in
the end effect, but currently has different priorities. And of course it
will be based on TeX in some kind not XSL. Cause they want to eliminate
TeX's drawbacks (including multilingual text) it perhaps makes sense to
get in touch with them too. BTW: They would like to use the Batik code
for reading TTF-files. I think there are Batik members here too? Perhaps
one of you could drop them a line...

Congratulations to your marriage from me too,
Christian Z.

Re: Java text geometry

[Peter B. West]

Christian,
Sorry it's taken me so long to get back to you on this.  What's UTA?
Peter
Christian Z. wrote:
Hi Peter,
I didn't have a look at your work yet. So perhaps there's no reason for
me to speak up at all.
I personally find the Java Text API hard to extend and not very modular.
So here's my request. Could you please provide some kind of hook in form
of an interface so that I can easily write a patch for UTA anytime?
You'll also need some kind of attributed string like Java provides in
its java.text package. Would be fine to have a place where I can grab
the input in a well defined format and pass the result back to FOP.
--
Peter B. West 

Re: Java text geometry

[Christian Z.]

Hi Peter,
I didn't have a look at your work yet. So perhaps there's no reason for
me to speak up at all.

I personally find the Java Text API hard to extend and not very modular.
So here's my request. Could you please provide some kind of hook in form
of an interface so that I can easily write a patch for UTA anytime?
You'll also need some kind of attributed string like Java provides in
its java.text package. Would be fine to have a place where I can grab
the input in a well defined format and pass the result back to FOP.

Thanks in advance,
Christian Z.

Java text geometry

[Peter B. West]

Fellow fops,
This is to update you on what I am doing with alt-design layout.
The central Java text layout class is java.awt.font.TextLayout.  The 
following description is edited from the API.

TextLayout is an immutable graphical representation of styled character 
data.

It provides the following capabilities:
* implicit bidirectional analysis and reordering, (1)
* cursor positioning and movement, including split cursors for 
mixed directional text,
* highlighting, including both logical and visual highlighting for 
mixed directional text,
* multiple baselines (roman, hanging, and centered), (2)
* hit testing,
* justification, (3)
* default font substitution, (4)
* metric information such as ascent, descent, and advance, (5) and
* rendering


The aspects of particular interest are numbered.
TextLayouts are graphical objects whose origin is at the intersection 
between the layout's baseline and its left edge.  This is irrespective 
of the text direction.  For the purposes of layout, then, the graphical 
boxes into which flows are laid out exist in an absolute t-b-l-r 
context, rather than a relative bpd-ipd one.  The upshot of this is that 
all layout can be performed using the absolute orientation, rather than 
the relative, and bidi text, e.g., will be have the correct orientation, 
even though horizontal alignment of line-areas will have to take account 
of the text direction.

Reference-orientation introduces new considerations, but not as far as 
the relationship between absolute and relative edges is concerned.  The 
Rec spells out that, '"reference-orientation" is a rotation and does not 
influence the correspondence mapping.'  Rotation can be accommodated by 
applying an Affine Transform when mapping the content-rectangle of a 
reference-area into its allocation-rectangle.

The case of vertical writing modes is unclear.  Even though 
java.awt.ComponentOrientation discusses four orientations - LT 
(left2right, top2bottom, e.g. English), RT (right2left, top2bottom, e.g. 
Hebrew), TL (top2bottom, left2right, e.g. Mongolian) and TR (top2bottom, 
right2left, e.g. Japanese), and has isHorizontal() and isLeftToRight() 
methods, only LEFT_TO_RIGHT and RIGHT_TO_LEFT static fields are defined. 
 When a ComponentOrientation is created for Locale.JAPAN, it returns 
true for both methods in 1.4.2.  It remains to be seem whether vertical 
mode TextLayouts will have an origin at the intersection of the baseline 
and the top edge, which I would expect.

These notes are, as I said, to keep you in touch with what I am doing in 
alt-design, and also to run these ideas past you to see if I am missing 
anything.

Peter
--
Peter B. West