Re: Re: RTF and table/column widths - table width attribute
- original Nachricht Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Mi 15 Mär 2006 19:33:17 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Mar 14, 2006, at 20:37, [EMAIL PROTECTED] wrote: > > > Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > > > >> Anyway, you'd have to go: > >> > >> Object o = property; > >> CompoundDatatype c = (CompoundDatatype) o; > > No, you don't have to. The property would have a method 'getCompound > > ()' returning a CompoundDatatype. Either it returns this, 'cause it > > is a CompoundDatatype or it returns a previously set instance > > (constructor, set-method) or it creates an instance, if necessary > > (maybe with default types) or even returns 'null' 'cause it's not > > able to deal with CompoundDatatype. So the only thing you need is a > > null-check on abstract levels, not a cast or instanceof. It may > > return a non-null value which maybe this, maybe an attribute, maybe > > a Singleton, whatever... > > OK. Now I see... Just like it is currently done with, for example, > Property.getList(), Property.getEnum() etc. (Correct?) Exactly > > Anyway, I thought about starting off with making that getObject() > method protected. AFAICT, it's never used outside of the properties > package, so in preparation for an eventual revision of this part of > the code, it seems wise to reduce that method's visibility to > indicate that it is meant for internal use only, so as not to > encourage its use elsewhere. > > WDYT? Sounds good to me, btw I think due to the strange naming and return value, most of the programmers won't call this method. But why not limiting access and mentioning something in the javadocs like "will be removed in future releases". There's no need to make it deprecated. If it's only used in the property-package, it 's not that hard to apply the changes to the necessary classes. > > Cheers, > > Andreas > > --- original Nachricht Ende "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
Re: RTF and table/column widths - table width attribute
On Mar 14, 2006, at 20:37, [EMAIL PROTECTED] wrote: Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> Anyway, you'd have to go: Object o = property; CompoundDatatype c = (CompoundDatatype) o; No, you don't have to. The property would have a method 'getCompound ()' returning a CompoundDatatype. Either it returns this, 'cause it is a CompoundDatatype or it returns a previously set instance (constructor, set-method) or it creates an instance, if necessary (maybe with default types) or even returns 'null' 'cause it's not able to deal with CompoundDatatype. So the only thing you need is a null-check on abstract levels, not a cast or instanceof. It may return a non-null value which maybe this, maybe an attribute, maybe a Singleton, whatever... OK. Now I see... Just like it is currently done with, for example, Property.getList(), Property.getEnum() etc. (Correct?) Anyway, I thought about starting off with making that getObject() method protected. AFAICT, it's never used outside of the properties package, so in preparation for an eventual revision of this part of the code, it seems wise to reduce that method's visibility to indicate that it is meant for internal use only, so as not to encourage its use elsewhere. WDYT? Cheers, Andreas
Re: Re: RTF and table/column widths - table width attribute
- original Nachricht Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Di 14 Mär 2006 18:25:15 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Mar 14, 2006, at 07:43, [EMAIL PROTECTED] wrote: > > > Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > > > >> BTW, dunno if you noticed, but you can pass a null into i.e. > >> LenthRangeProperty.getOptimum() to get to the underlying Property, > >> without the need for a PercentBaseContext... > >> (~ something like: LengthRangeProperty.getOptimum(null).getNumeric > >> ().getValue()?) > > No, I didn't notic this, maybe it should be mentioned in the > > javadocs (which are sometimes a bit short of information). It's not > > obvious to me, that a LengthRangeProperty is a replacement for the > > width-attribute. Maybe the javadoc comment should be something like > > this: > > Good point! I must admit that I stumbled upon this myself (in > LengthRangeProperty.getString()), trying to solve your problem... ;) added to the Todo, to lookup doc-less classes and get some information 'bout it...if it's not easier for the "creator" to commit comments to trunk (answering my questions may result in more text *g*) > > > Additionaly getWidth should be declared deprecated (again the > > compiler helps to find every use of deprecated API...blabla) and > > people like me, sticking to the javadocs, won't ask that much. And > > a bit earlier on this topic it was said, that maybe some features > > from my work, e.g. the parent-attribute of PercentBaseContext- > > realization, may be moved to a more abstract layer. Every > > LayoutManager has a parent (except the root), RTF export needs > > something similar, so why not moving it towards direction of > > abstraction. > > Also a worthwhile suggestion. Don't let us stop you! :) > How 'bout introducing an AbstractPercentBaseContext which already > offers a very basic implementation for some methods? If I do such basic changes I always create an abstract class, 'cause keeping track of the parent, returning the root and so on is that primitive, that real programmers shouldn't be bored with that kind of work *g* > > But a method "getObject" returning "this" is not necessary, every > > class is instanceof Object so you can assign any instance to a > > variable of type "Object" and calling methods like HashMap.put or > > ArrayList.add results (after widening conversion) > > Yes, but this does mean declaring a new local variable to hold the > result, which I suppose the original programmer wanted to avoid (? > guessing here, since I'm not the author... I'm just trying to make > sense of it --maybe there is none :)) Mkay, but if it's not necessary to hold an attribute, than you should think over again the class' associations and leave this one out. If they don't belong together, don't force 'em... > > Anyway, you'd have to go: > > Object o = property; > CompoundDatatype c = (CompoundDatatype) o; No, you don't have to. The property would have a method 'getCompound()' returning a CompoundDatatype. Either it returns this, 'cause it is a CompoundDatatype or it returns a previously set instance (constructor, set-method) or it creates an instance, if necessary (maybe with default types) or even returns 'null' 'cause it's not able to deal with CompoundDatatype. So the only thing you need is a null-check on abstract levels, not a cast or instanceof. It may return a non-null value which maybe this, maybe an attribute, maybe a Singleton, whatever... [...] > > Maybe the properties should have a getCompoundDatatype-method which > > may return "null". > > Now, this would make sense if 50% (or more) of all FO-properties were > compound, but I'm roughly guessing that it's closer to 15% (? widths, > space-*, keep-*... any others). It makes sense to me if only 1% may return a CompoundDatatype, more sense than returning just Object. But this is personal taste. Maybe the design has a weakness and the author assumed, that a CompoundDatatype is more special than a non-compound. But I may also do it the other way around and say, that all Datatypes are compound, while the non-compounds leave out the abstract part. But you're right, that this is no use, if it affects only 15%. [...] > I see. So it is a matter of preference/personal taste? Well, the > point is exactly that this method serves to switch the runtime type > of a Property instance, without having to perform a cast
Re: RTF and table/column widths - table width attribute
On Mar 14, 2006, at 07:43, [EMAIL PROTECTED] wrote: Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> BTW, dunno if you noticed, but you can pass a null into i.e. LenthRangeProperty.getOptimum() to get to the underlying Property, without the need for a PercentBaseContext... (~ something like: LengthRangeProperty.getOptimum(null).getNumeric ().getValue()?) No, I didn't notic this, maybe it should be mentioned in the javadocs (which are sometimes a bit short of information). It's not obvious to me, that a LengthRangeProperty is a replacement for the width-attribute. Maybe the javadoc comment should be something like this: Good point! I must admit that I stumbled upon this myself (in LengthRangeProperty.getString()), trying to solve your problem... ;) Additionaly getWidth should be declared deprecated (again the compiler helps to find every use of deprecated API...blabla) and people like me, sticking to the javadocs, won't ask that much. And a bit earlier on this topic it was said, that maybe some features from my work, e.g. the parent-attribute of PercentBaseContext- realization, may be moved to a more abstract layer. Every LayoutManager has a parent (except the root), RTF export needs something similar, so why not moving it towards direction of abstraction. Also a worthwhile suggestion. Don't let us stop you! :) How 'bout introducing an AbstractPercentBaseContext which already offers a very basic implementation for some methods? AFAICT, at first glance this seems to be used to cast certain types of Property instances to generic Objects before re-casting them to fit the CompoundDatatype interface --the latter cast will definitely not pass the compilation stage, since Property does not implement CompoundDatatype (= not all properties are compound properties). What if the programmer knows beforehand that this cast *will* succeed? The only viable option seems to be to trick the compiler into believing that it just might work... Convenient, no? :) But a method "getObject" returning "this" is not necessary, every class is instanceof Object so you can assign any instance to a variable of type "Object" and calling methods like HashMap.put or ArrayList.add results (after widening conversion) Yes, but this does mean declaring a new local variable to hold the result, which I suppose the original programmer wanted to avoid (? guessing here, since I'm not the author... I'm just trying to make sense of it --maybe there is none :)) Anyway, you'd have to go: Object o = property; CompoundDatatype c = (CompoundDatatype) o; or even: CompoundDatatype c = (CompoundDatatype) ((Object) property); where we currently have: CompoundDatatype c = (CompoundDatatype) property.getObject(); in calling the method containing "Object" in it's signature. It makes no sense to me to reprogram the widening conversion and it's not really good programming style to do that much type-guessing and casting. It's not really 'type-guessing' here. The Property instance in question is guaranteed to be an instance of a class implementing CompoundDatatype... for other properties, the methods PropertyMaker.getSubprop() and .setSubprop() will never be called. It needs time and is a possible source for runtime errors (ClassCastException...) if not properly used. Note: *if* not properly used... Now, you weren't going to use it improperly, were you? ;P Just kidding, of course. Well, it won't lead to a runtime error here (see above), and declaring a new local variable also takes time (as does the double cast), so this still does not convince me... Maybe the properties should have a getCompoundDatatype-method which may return "null". Now, this would make sense if 50% (or more) of all FO-properties were compound, but I'm roughly guessing that it's closer to 15% (? widths, space-*, keep-*... any others). I also seem to remember getObject() being used in the J2SE API itself, just can't remember where exactly. Maybe I'm imagining things, maybe I'm not and that's where the original author got the idea in the first place (?) Let's call it a facade or a factory method. So you the compiler helps you in finding errors (someone calling this facade or factory method and assigning it to the wrong type...). There are two ways in Java to emulate multiple inheritance, either you use multiple interfaces and do some instanceof-checks, I prefer the facade- or factory-pattern. The more common objects has methods to access the less common object or may create a non persistent object, containing the other interface's features. Depends on personal taste (I dislike casting against the direction of abstraction, the other direction is made by the VM). I see. So it is a matter of preference/personal taste? Well, the point is exactly that this method serves to switch the runtime type of a Property instance, without having to perform a cast... Still don't like it?
Re: Re: RTF and table/column widths - table width attribute
- original Nachricht Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Mo 13 Mär 2006 20:39:59 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Mar 13, 2006, at 19:53, [EMAIL PROTECTED] wrote: > > Hi, > [...] > I guess, if the RTF renderer --as was already suggested-- needs to > keep its fingers out of the layout package, then the correct way to > go about that --at least, IMO-- would be to have one class in the RTF > package implement the PercentBaseContext interface. An instance of > that class can then be used inside the RTFHandler, and passed back > into the properties subsystem, without having to import anything from > the layout package. I'm doing it exactly in this way, additionally my realization of PercentBaseContext may have a parent, so a table inside a block is rendered with the correct indenting... > > BTW, dunno if you noticed, but you can pass a null into i.e. > LenthRangeProperty.getOptimum() to get to the underlying Property, > without the need for a PercentBaseContext... > (~ something like: LengthRangeProperty.getOptimum(null).getNumeric > ().getValue()?) No, I didn't notic this, maybe it should be mentioned in the javadocs (which are sometimes a bit short of information). It's not obvious to me, that a LengthRangeProperty is a replacement for the width-attribute. Maybe the javadoc comment should be something like this: /** * Returns the LengthRangeProperty from left border to right border. Call this * method like * LengthRangeProperty.getOptimum(null) * to have a default length-object. * * @since 0.91 */ Additionaly getWidth should be declared deprecated (again the compiler helps to find every use of deprecated API...blabla) and people like me, sticking to the javadocs, won't ask that much. And a bit earlier on this topic it was said, that maybe some features from my work, e.g. the parent-attribute of PercentBaseContext-realization, may be moved to a more abstract layer. Every LayoutManager has a parent (except the root), RTF export needs something similar, so why not moving it towards direction of abstraction. > > > In additional this getObject-topic is still open... > > Eclipse's call hierarchy shows these methods are definitely being > used... > > AFAICT, at first glance this seems to be used to cast certain types > of Property instances to generic Objects before re-casting them to > fit the CompoundDatatype interface --the latter cast will definitely > not pass the compilation stage, since Property does not implement > CompoundDatatype (= not all properties are compound properties). What > if the programmer knows beforehand that this cast *will* succeed? The > only viable option seems to be to trick the compiler into believing > that it just might work... Convenient, no? :) But a method "getObject" returning "this" is not necessary, every class is instanceof Object so you can assign any instance to a variable of type "Object" and calling methods like HashMap.put or ArrayList.add results (after widening conversion) in calling the method containing "Object" in it's signature. It makes no sense to me to reprogram the widening conversion and it's not really good programming style to do that much type-guessing and casting. It needs time and is a possible source for runtime errors (ClassCastException...) if not properly used. Maybe the properties should have a getCompoundDatatype-method which may return "null". Let's call it a facade or a factory method. So you the compiler helps you in finding errors (someone calling this facade or factory method and assigning it to the wrong type...). There are two ways in Java to emulate multiple inheritance, either you use multiple interfaces and do some instanceof-checks, I prefer the facade- or factory-pattern. The more common objects has methods to access the less common object or may create a non persistent object, containing the other interface's features. Depends on personal taste (I dislike casting against the direction of abstraction, the other direction is made by the VM). I don't want to teach a how-to-program-lesson, but all my questions are caused by a lack of information in the code/ javadocs. Maybe some other future contributers don't ask that much (sometimes I'm quite annoying) and uncomment some attributes and causing much more damaga than being helpful. Or there's a FOP-cookbook, which I haven't read yet but ought to study, before spamming the dev-list...(You know, what you did, I must understand first, how you thought at this moment, to understand, why the code's done this way to do it the same.) "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
Re: RTF and table/column widths - table width attribute
On Mar 13, 2006, at 19:53, [EMAIL PROTECTED] wrote: Hi, forget everything I said about that Length- and unit-retrieval from fo.flows, I've found the mistake. I'll do it the other way 'round, instead of calculating from the fixed to the proportional ones I'll hand it over to the PercentBaseContext first (normalizing proportional and percentage widths to values <1.0). If table width- attribute is "auto", I'll assume 100% width. Though I need the table's width if it's not proportional or auto, e.g. width="190mm". I don't really see the problem in that. I guess, if the RTF renderer --as was already suggested-- needs to keep its fingers out of the layout package, then the correct way to go about that --at least, IMO-- would be to have one class in the RTF package implement the PercentBaseContext interface. An instance of that class can then be used inside the RTFHandler, and passed back into the properties subsystem, without having to import anything from the layout package. BTW, dunno if you noticed, but you can pass a null into i.e. LenthRangeProperty.getOptimum() to get to the underlying Property, without the need for a PercentBaseContext... (~ something like: LengthRangeProperty.getOptimum(null).getNumeric ().getValue()?) In additional this getObject-topic is still open... Eclipse's call hierarchy shows these methods are definitely being used... AFAICT, at first glance this seems to be used to cast certain types of Property instances to generic Objects before re-casting them to fit the CompoundDatatype interface --the latter cast will definitely not pass the compilation stage, since Property does not implement CompoundDatatype (= not all properties are compound properties). What if the programmer knows beforehand that this cast *will* succeed? The only viable option seems to be to trick the compiler into believing that it just might work... Convenient, no? :) Cheers, Andreas
Re: Re: RTF and table/column widths - table width attribute
Hi again, forget everything I said about that Length- and unit-retrieval from fo.flows, I've found the mistake. I'll do it the other way 'round, instead of calculating from the fixed to the proportional ones I'll hand it over to the PercentBaseContext first (normalizing proportional and percentage widths to values <1.0). If table width-attribute is "auto", I'll assume 100% width. Though I need the table's width if it's not proportional or auto, e.g. width="190mm". In additional this getObject-topic is still open... 1 Million Singles in Ihrer Nahe. Finden Sie Ihren Traumpartner bei Deutschlands beliebtester Partnerboerse: http://singles.freenet.de/index.html?pid=11512
Re: Re: RTF and table/column widths - table width attribute
- original Nachricht Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Mo 13 Mär 2006 08:19:05 CET Von: [EMAIL PROTECTED] > "getObject"? According to the "widening controversion" in the java language > specification It's only "conversion", early morning... Ihr Traumpartner ist nur einen Klick entfernt. 1 Million Singles warten auf Sie in Deutschlands beliebtester Partnerboerse: http://singles.freenet.de/index.html?pid=11512
Re: RTF and table/column widths - table width attribute
Hi, how do I get it, the attribute value and why is "fo.flow.Table.width" uncommented? (It should either be removed with additional comments about the change or uncommented again with a method to get/set it) If it is the inlineLengthRangeProperty I'm quite upset, 'cause I'm running again into the same design problem mentioned in the mail before: I cannot calculate an object's with using a PercentBaseContext, if I have to determine it's width first - I'm running in circles. The only thing I need is an abstract access to all the width's parameters, the value (numeric) and the dimension, so I can translate it without having a LayoutManager (which is not available for RTF-output and makes no sense for a streamed output format). BTW, why does the LengthRangeProperty return a LengthRangeProperty without any parameter (LengthRangeProperty.getLengthRange())? Does it make sense to ask a variable for it's own reference (what else should this method return besides "this")? (Method is not static, too) And why is there a method "getObject"? According to the "widening controversion" in the java language specification every instance is an object, there's no need for such a method (would be the same like casting "null" into any class, you can even call an integer's getClass() method...) What am I trying to say? There's either a plenty of methods without any necessity and the right ones are missing or I'll have to spent much more time on understanding FOP, being so much different from other java apps I've seen...(Maybe therefore the first thing I should do before continueing my work should be a UML diagram of the layout manager concept and it's interface to the different rendering packages and a sequence diagram of the RTF export.) The easy way would be to remove these methods and see, who's moaning 'bout it, when compiling. But first: discussion on that... Noch allein? 1 Million Singles warten auf ein Date! Schnell Kontakt aufnehmen bei Deutschlands beliebtester Partnerboerse http://singles.freenet.de/index.html?pid=11512
RTF and table/column widths
Hi there, after being silent for I while, I have some questions, only to be sure. First one is raised by the following table column attributes: width=1.1; width=3pt; null; width=22%; width=19mm; I implemented it like this: 1. determine smallest fixed width 2. if no smallest fixed width is given: 2.1 sum up all weights 2.2 divide table's total width by sum of weights 2.3 muliply each weight with this factor 3. else 3.1 multiply all weights with the smalles fixed width 3.2 sum up all percentages 3.3 determine width of 1% based on available fixed widths (1., 3.1) 3.4 multiply all percentages with 1%-width So according to the numbers above the widths will be (mpt): #0=3300 #1=3000 #2=3000 #3=17814 #4=53858 Correct any of the decisions if I'm wrong. I made some dirty hack to get the right unit from anonymous Length-interface-realizations (instanceof-operator) and found PercentLength.value()-method in a twilight zone (cite: "really necessary?"), every other Length-realization is able to return the "naked" value (TableColLength.getTableUnits(), FixedLength.getValue()<- no context!). Is there another way calculating the widths more "polite" (I don't like instanceof-operations, casts and that sort of thing, Length should be able to return the unit and the value, in addition to a value filtered through the PercentBaseContext)? I'm quite unsatisfied, due to the fact, that I did nothing RTF-specific until now. Did I re-invent the column-width-algorithm, is it hidden somewhere and already working fine? (I've attached the fo.flow.TableColumn to the rtf.TableContext and calculated the widths when the first row starts, maybe the Table should do this on it's own, being a column container, returning the widths if needed...which would lead to a stateful parser instead of re-programming the same state-objects and -transitions for every rendering engine). It's getting more and more like a basic LayoutManager (being nested, holding fo.flow-objects, doing some calculations...) Thanks for any comment, maybe I'll finish this chapter this week, opening some sort of discussion about moving some basic functionalities to a more abstract level. Thanks for being patient... "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
Re: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
- original Nachricht Betreff: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users)) Gesendet: Sa 04 Mär 2006 11:53:19 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > You're quite right, I believe. Any changes to this will lead to a > marginal overall improvement at best. Mkay > > This whole thing got me wondering, though, if there are any other > places in the rtf-lib where characters outside of the 7-bit ASCII > range are incorrectly written to the output as characters (instead of > passing through RtfStringConverter to do unicode escapes). I'll look through this, write some fancy test documents. I'm starting right now with my suggested improvements on the proportional width calculations. Maybe I dig out some other issues... > > We'll keep looking as well. > > Thanks for your input/feedback! NP at all > > Cheers, > > Andreas > > --- original Nachricht Ende 1 Million Singles in Ihrer Nahe. Finden Sie Ihren Traumpartner bei Deutschlands beliebtester Partnerboerse: http://singles.freenet.de/index.html?pid=11512
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Mar 4, 2006, at 11:19, [EMAIL PROTECTED] wrote: Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> On Mar 1, 2006, at 08:46, [EMAIL PROTECTED] wrote: You changed the Writer.write to StringBuffer operations. I'd say that appending to a StringBuffer is much slower than writing directly to a BufferedOutputStream. Really? Well, I have to admit, this was a late-night idea :-/ And I didn't read the TechTips for a long time: http://java.sun.com/developer/TechTips/1998/tt0120.html So String vs. StringBuffer is 1:1/6 (StringBuffer.append is six times faster or needs only a sixth than concatenating Strings). And StringBuffer.append->Writer vs. String->BufferedWriter is not mentioned that explicitly anywhere, but if both are StringBuffer- techniques, this is only two times slower. As said before, RTF is quite fast, no layout managing, that sort of thing. So not that bad at all... You're quite right, I believe. Any changes to this will lead to a marginal overall improvement at best. This whole thing got me wondering, though, if there are any other places in the rtf-lib where characters outside of the 7-bit ASCII range are incorrectly written to the output as characters (instead of passing through RtfStringConverter to do unicode escapes). We'll keep looking as well. Thanks for your input/feedback! Cheers, Andreas
Re: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
- original Nachricht Betreff: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users)) Gesendet: Mi 01 Mär 2006 19:22:24 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Mar 1, 2006, at 08:46, [EMAIL PROTECTED] wrote: > > > You changed the Writer.write to StringBuffer operations. I'd say > > that appending to a StringBuffer is much slower than writing > > directly to a BufferedOutputStream. > > Really? Well, I have to admit, this was a late-night idea :-/ And I didn't read the TechTips for a long time: http://java.sun.com/developer/TechTips/1998/tt0120.html So String vs. StringBuffer is 1:1/6 (StringBuffer.append is six times faster or needs only a sixth than concatenating Strings). And StringBuffer.append->Writer vs. String->BufferedWriter is not mentioned that explicitly anywhere, but if both are StringBuffer-techniques, this is only two times slower. As said before, RTF is quite fast, no layout managing, that sort of thing. So not that bad at all... > > Maybe we could make sure the Writer is wrapped into a BufferedWriter > when creating it in RTFHandler, just to streamline a bit. I'll have a look at this. (I was quite busy with other stuff, but today I'll finish some FOP tasks) "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Mar 3, 2006, at 23:31, Andreas L Delmelle wrote: On Mar 1, 2006, at 19:21, Andreas L Delmelle wrote: New tiny patch proposal for this below. Nothing broke, and strictly RTF-wise the output for list-item-label text now seems more correct than before. Unfortunately, I lack extensive tests for this sort of thing, so I wouldn't mind a second opinion --especially WRT the generated RTF code. I tried to make sure nothing was altered apart from the way the characters for those labels are written to the output stream, but you never know... Just noticed that there still seems to be a problem related to the hardcoding of the font to use. This is always set to \f2, which may or may not contain glyphs for the characters in question...? Cheers, Andreas
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Mar 1, 2006, at 19:21, Andreas L Delmelle wrote:
Maybe we could make sure the Writer is wrapped into a
BufferedWriter when creating it in RTFHandler, just to streamline a
bit.
I'd drop that static Map anyways. Makes sense if you need the same
constant in a hundred different places, but since all remains
private to that tiny class here, they could as well be hardcoded.
Work directly on the char primitive instead of the Character object
as much as possible. (?)
New tiny patch proposal for this below. Nothing broke, and strictly
RTF-wise the output for list-item-label text now seems more correct
than before. Unfortunately, I lack extensive tests for this sort of
thing, so I wouldn't mind a second opinion --especially WRT the
generated RTF code. I tried to make sure nothing was altered apart
from the way the characters for those labels are written to the
output stream, but you never know...
TIA,
Andreas
Index: src/java/org/apache/fop/render/rtf/RTFHandler.java
===
--- src/java/org/apache/fop/render/rtf/RTFHandler.java (revision
382930)
+++ src/java/org/apache/fop/render/rtf/RTFHandler.java (working copy)
@@ -19,6 +19,7 @@
package org.apache.fop.render.rtf;
// Java
+import java.io.BufferedWriter;
import java.io.IOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
@@ -52,9 +53,9 @@
import org.apache.fop.fo.flow.ListItemLabel;
import org.apache.fop.fo.flow.PageNumber;
import org.apache.fop.fo.flow.Table;
-import org.apache.fop.fo.flow.TableColumn;
import org.apache.fop.fo.flow.TableBody;
import org.apache.fop.fo.flow.TableCell;
+import org.apache.fop.fo.flow.TableColumn;
import org.apache.fop.fo.flow.TableHeader;
import org.apache.fop.fo.flow.TableRow;
import org.apache.fop.fo.pagination.Flow;
@@ -147,7 +148,8 @@
public void startDocument() throws SAXException {
// TODO sections should be created
try {
-rtfFile = new RtfFile(new OutputStreamWriter(os));
+rtfFile = new RtfFile(new BufferedWriter(
+new OutputStreamWriter(os, "US-ASCII")));
docArea = rtfFile.startDocumentArea();
} catch (IOException ioe) {
// TODO could we throw Exception in all FOEventHandler
events?
Index: src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java
===
--- src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java (revision 382930)
+++ src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java (working copy)
@@ -63,7 +63,8 @@
item.writeGroupMark(true);
//item.writeControlWord("pndec");
item.writeOneAttribute(RtfListTable.LIST_FONT_TYPE, "2");
-item.writeControlWord("pntxtb " + text);
+item.writeControlWord("pntxtb ");
+RtfStringConverter.getInstance().writeRtfString(item.writer,
text);
item.writeGroupMark(false);
}
@@ -102,8 +103,9 @@
sCount = "0" + sCount;
}
}
-element.writeOneAttributeNS(
-RtfListTable.LIST_TEXT_FORM, "\\'" + sCount + text);
+element.writeControlWordNS(RtfListTable.LIST_TEXT_FORM + "\
\'" + sCount);
+RtfStringConverter.getInstance().writeRtfString(
+element.writer, text);
element.writeGroupMark(false);
element.writeGroupMark(true);
Index: src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java
===
--- src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java(revision 382930)
+++ src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java(working copy)
@@ -1,5 +1,5 @@
/*
- * Copyright 1999-2004 The Apache Software Foundation.
+ * Copyright 1999-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -26,8 +26,6 @@
package org.apache.fop.render.rtf.rtflib.rtfdoc;
-import java.util.Map;
-import java.util.HashMap;
import java.io.IOException;
import java.io.Writer;
@@ -38,23 +36,6 @@
public class RtfStringConverter {
private static final RtfStringConverter INSTANCE = new
RtfStringConverter();
-private static final Map SPECIAL_CHARS;
-private static final Character DBLQUOTE = new Character('\"');
-private static final Character QUOTE = new Character('\'');
-private static final Character SPACE = new Character(' ');
-
-/** List of characters to escape with corresponding replacement
strings */
-static {
-SPECIAL_CHARS = new HashMap();
-SPECIAL_CHARS.put(new Character('\t'), "tab");
-SPECIAL_CHARS.put(new Character('\n'), "line");
-SPECIAL_CHARS.put(new Character('\''), "rquote");
-
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Mar 1, 2006, at 08:46, [EMAIL PROTECTED] wrote: You changed the Writer.write to StringBuffer operations. I'd say that appending to a StringBuffer is much slower than writing directly to a BufferedOutputStream. There was a comparison between static concatenation, concatenation of Strings (variables) during runtime and appending characters to a StringBuffer. I don't remember the factor, but it was significant. Afterall RTF-export is not time critic and runs smooth and maybe the usage of StringBuffer.append is encouraged (due to incredible speed up in newer SDKs...whatever)...any comments? Really? Well, I have to admit, this was a late-night idea :-/ Maybe we could make sure the Writer is wrapped into a BufferedWriter when creating it in RTFHandler, just to streamline a bit. I'd drop that static Map anyways. Makes sense if you need the same constant in a hundred different places, but since all remains private to that tiny class here, they could as well be hardcoded. Work directly on the char primitive instead of the Character object as much as possible. (?) Cheers, Andreas
Re: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
- original Nachricht Betreff: Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users)) Gesendet: Mi 01 Mär 2006 00:45:39 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Feb 28, 2006, at 23:17, Andreas L Delmelle wrote: > > > > > Is it allowed to use unicode escapes in control words? If so, the > > solution could be as simple as using RTFStringConverter to escape > > any 'text' if necessary. > > > > In practice, my proposal would come down to > > On that note, while browsing through the related sources, found some > room for minor optimization in the RtfStringConverter itself. If this > deals with many and/or large portions of text: see below. > > If no one objects... > You changed the Writer.write to StringBuffer operations. I'd say that appending to a StringBuffer is much slower than writing directly to a BufferedOutputStream. There was a comparison between static concatenation, concatenation of Strings (variables) during runtime and appending characters to a StringBuffer. I don't remember the factor, but it was significant. Afterall RTF-export is not time critic and runs smooth and maybe the usage of StringBuffer.append is encouraged (due to incredible speed up in newer SDKs...whatever)...any comments? Ihr Traumpartner ist nur einen Klick entfernt. 1 Million Singles warten auf Sie in Deutschlands beliebtester Partnerboerse: http://singles.freenet.de/index.html?pid=11512
Re: RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Feb 28, 2006, at 23:17, Andreas L Delmelle wrote:
Is it allowed to use unicode escapes in control words? If so, the
solution could be as simple as using RTFStringConverter to escape
any 'text' if necessary.
In practice, my proposal would come down to
On that note, while browsing through the related sources, found some
room for minor optimization in the RtfStringConverter itself. If this
deals with many and/or large portions of text: see below.
If no one objects...
Cheers,
Andreas
Index: src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java
===
--- src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java(revision 381394)
+++ src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfStringConverter.java(working copy)
@@ -1,5 +1,5 @@
/*
- * Copyright 1999-2004 The Apache Software Foundation.
+ * Copyright 1999-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -26,8 +26,6 @@
package org.apache.fop.render.rtf.rtflib.rtfdoc;
-import java.util.Map;
-import java.util.HashMap;
import java.io.IOException;
import java.io.Writer;
@@ -38,23 +36,6 @@
public class RtfStringConverter {
private static final RtfStringConverter INSTANCE = new
RtfStringConverter();
-private static final Map SPECIAL_CHARS;
-private static final Character DBLQUOTE = new Character('\"');
-private static final Character QUOTE = new Character('\'');
-private static final Character SPACE = new Character(' ');
-
-/** List of characters to escape with corresponding replacement
strings */
-static {
-SPECIAL_CHARS = new HashMap();
-SPECIAL_CHARS.put(new Character('\t'), "tab");
-SPECIAL_CHARS.put(new Character('\n'), "line");
-SPECIAL_CHARS.put(new Character('\''), "rquote");
-SPECIAL_CHARS.put(new Character('\"'), "rdblquote");
-SPECIAL_CHARS.put(new Character('\\'), "\\");
-SPECIAL_CHARS.put(new Character('{'), "{");
-SPECIAL_CHARS.put(new Character('}'), "}");
-}
-
/** singleton pattern */
private RtfStringConverter() {
}
@@ -79,43 +60,50 @@
return;
}
+StringBuffer sb = new StringBuffer();
+String replacement;
+char c, d;
// TODO: could be made more efficient (binary lookup, etc.)
-for (int i = 0; i < str.length(); i++) {
-final Character c = new Character(str.charAt(i));
-Character d;
-String replacement;
-if (i != 0) {
-d = new Character(str.charAt(i - 1));
-} else {
-d = new Character(str.charAt(i));
+for (int i = -1; ++i < str.length();) {
+replacement = null;
+c = str.charAt(i);
+switch (c) {
+case '\"':
+case '\'':
+d = str.charAt((i == 0) ? i : i - 1);
+if (d == ' ') {
+replacement = (c == '\"') ? "ldblquote" : "lquote";
+} else {
+replacement = (c == '\"') ? "rdblquote" : "rquote";
+}
+break;
+case '\t':
+replacement = "tab";
+break;
+case '\n':
+replacement = "line";
+break;
+case '\\':
+case '{':
+case '}':
+replacement = "" + c;
+break;
+default:
+//nop
}
-//This section modified by Chris Scott
-//add "smart" quote recognition
-if (c.equals((Object)DBLQUOTE) && d.equals((Object)
SPACE)) {
-replacement = "ldblquote";
-} else if (c.equals((Object)QUOTE) && d.equals((Object)
SPACE)) {
-replacement = "lquote";
-} else {
-replacement = (String)SPECIAL_CHARS.get(c);
-}
-
if (replacement != null) {
// RTF-escaped char
-w.write('\\');
-w.write(replacement);
-w.write(' ');
-} else if (c.charValue() > 127) {
+sb.append('\\').append(replacement).append(' ');
+} else if (c > 127) {
// write unicode representation - contributed by
Michel Jacobson
// <[EMAIL PROTECTED]>
-w.write("\\u");
-w.write(Integer.toString((int)c.charValue()));
-w.write("\\\'3f");
+sb.append("\\u").append((int) c).append("\\\'3f");
} else {
// plain char that is understood by RTF natively
-w.write(c.charValue());
+sb.append(c);
}
}
+w.write(sb.toStr
RTF - list-item-label encoding (was: RTF and table/column widths (moved from fop-users))
On Feb 28, 2006, at 19:39, Andreas L Delmelle wrote:
Already took a closer look at this, and this seemed already handled
in RTFStringConverter.
So, I wondered and wandered, and found that --see
RTFListItem.RTFListItemLabel-- currently RTFListStyleBullet is
unused. We know only RTFListStyleNumber and RTFListStyleText.
OK, so the error qua encoding is two-fold here:
- RTFHandler should force the OutputStreamWriter to use "US-ASCII"
encoding
- RTFListStyleText writes the bullet as 'text' (part of a control
word) to the OutputStream
Is it allowed to use unicode escapes in control words? If so, the
solution could be as simple as using RTFStringConverter to escape any
'text' if necessary.
In practice, my proposal would come down to
Index: src/java/org/apache/fop/render/rtf/RTFHandler.java
===
--- src/java/org/apache/fop/render/rtf/RTFHandler.java (revision
381394)
+++ src/java/org/apache/fop/render/rtf/RTFHandler.java (working copy)
@@ -147,7 +147,7 @@
public void startDocument() throws SAXException {
// TODO sections should be created
try {
-rtfFile = new RtfFile(new OutputStreamWriter(os));
+rtfFile = new RtfFile(new OutputStreamWriter(os, "US-
ASCII"));
docArea = rtfFile.startDocumentArea();
} catch (IOException ioe) {
// TODO could we throw Exception in all FOEventHandler
events?
Index: src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java
===
--- src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java (revision 381394)
+++ src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/
RtfListStyleText.java (working copy)
@@ -63,7 +63,8 @@
item.writeGroupMark(true);
//item.writeControlWord("pndec");
item.writeOneAttribute(RtfListTable.LIST_FONT_TYPE, "2");
-item.writeControlWord("pntxtb " + text);
+item.writeControlWord("pntxtb ");
+RtfStringConverter.getInstance().writeRtfString(item.writer,
text);
item.writeGroupMark(false);
}
Any objections? Suggestions for a better approach? (seems more like a
quick fix; besides that, untested yet)
Cheers,
Andreas
Re: RTF and table/column widths (moved from fop-users)
Absolutely! On 28.02.2006 19:39:26 Andreas L Delmelle wrote: > Anyway, relying on the default platform > encoding is just as definitely wrong. :-) Jeremias Maerki
RTF and table/column widths (moved from fop-users)
(was getting a bit too much OT for fop-users...) On Feb 28, 2006, at 19:07, Jeremias Maerki wrote: On 28.02.2006 18:25:42 Andreas L Delmelle wrote: I think I found what's causing the question-marks to appear in the RTF output... See org.apache.fop.render.rtf.RTFHandler, line 150. An OutputStreamWriter is instantiated, which uses the default platform encoding. Should be enough to force this Writer to use UTF-8, I think. Nope, according to the RTF spec, the output should be in "US-ASCII" (7-bit) for portability. UTF-8 is definitely not supported by RTF Oops! Sorry, my mistake. Anyway, relying on the default platform encoding is just as definitely wrong. :-) but I think it's possible to use various 8-bit character sets and Unicode escapes if the proper commands are generated. The Microsoft RTF spec lists what is possible. Already took a closer look at this, and this seemed already handled in RTFStringConverter. So, I wondered and wandered, and found that --see RTFListItem.RTFListItemLabel-- currently RTFListStyleBullet is unused. We know only RTFListStyleNumber and RTFListStyleText. Cheers, Andreas
