Re: DO NOT REPLY [Bug 27901] - TextCharIterator.remove() does not work properly
Am Do, den 25.03.2004 schrieb Glen Mazza um 22:38: Ich bin confused--ist chz ([EMAIL PROTECTED])--Christian Geisert oder anderer Christian? The bugzilla entry lists chz as being Christian Z, so I'm not sure whom I'm speaking with! Christian Ziesemer chz I adjusted that. If the language has no space (Japanese, or Thai I guess) then this particular portion, of whitespace removal is not relevant I would guess--I think dictionaries are needed for hyphenation, not space removal, no? I don't know the whole context the FOText class is used, so if it's only used for space removal -- then of course you've nothing to do in Thai and therefore limited use for changing. :-) Christian Z.
Announcement: Unified Typesetting API
Dear list, after several months of work I want to announce the first release of the Unified Typesetting API. The Unified Typesetting API (UTA) is an attempt to unify the typesetting process needed by every text handling application. Currently it provides a reference implementation in Java available under the Mozilla Public License. Features: * line-breaking model similar to TeX's to allow global optimizing line-break algorithms (stable) * modular and extensible design to allow simple as well as high quality implementations * support for new scripts can easily be added (in progress) * quality management component to retrieve information about the internals of a typesetter (stable) * fully documented * open source Source and documentation is available under http://inghuimische.drhuim.de/uta Christian Ziesemer
Re: Java text handling
Hi Peter! Do any of the list denizens have experience with Java font handling and 2D text layout? I'm new to it, and would like to be able to bounce questions off someone further up the food chain, on or off-line. The typesetting is done Font.layoutGlyphVector and java.awt.font.GlyphVector.performDefaultLayout. Currently TrueType is supported and therefore the philosophy 'do everything within the font'. This makes the Java API very hard to extend and not very modular. Cause OpenType follows the philosophy 'do as much of the typesetting within the application' it's hard to support both the same time. There are typesetting issues which are font dependent and some which are not. My advice: Use UTA and provide a wrapper around the Java font class in form of a Script [1]. ;-) Regards, Christian Ziesemer [1] http://inghuimische.drhuim.de/uta/javadoc/de/inghuimische/uta/typeset/Script.html
Re: Java text handling
Hi Jeremias! There is a graph subproject inside Jakarta Commons. Maybe this could be used instead of JGraphT. I'll have a look at it, thanks. Anyway, how does UTA relate to Luca's recent patch on line breaking? In no way. While Luca seems to have reimplemented the glue/box/penalty model, I have a generalization/simplification. I think it is similar to what Knuth mentions in the Addendum in Digital Typography, Breaking Paragraphs into Lines, as socalled kerfs model. In UTA there are only Items. A break is allowed behind every item, an item has a penalty and different widths depending on its position. Christian Ziesemer
Re: Java text geometry
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.
Re: Java text geometry
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
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: FW: DO NOT REPLY [Bug 32201] - please, provide a manpage
Unless Docbook can generate manpages, we would also have the problem of needing to maintain two sets of documentation (online and manpage) to say the same thing. Though never generated a man page on my own, DocBook seems to do it. Have a look at: http://docbook.org/tdg/en/html/ch02.html#making-refentry http://linuxwiki.de/ManPage states that you need the docbook-utils (docbook2man) to generate a man page out of docbook. Regards, Christian Z.
