cvs commit: xml-fop/src/java/org/apache/fop/render/rtf ListAttributesConverter.java RTFHandler.java TableAttributesConverter.java TextAttributesConverter.java

[gmazza]

gmazza  2003/12/19 22:53:23

  Modified:src/codegen properties.xsl
   src/java/org/apache/fop/area AreaTree.java
   src/java/org/apache/fop/fo FObj.java FObjMixed.java
PropertyList.java PropertyManager.java
   src/java/org/apache/fop/fo/expr BodyStartFunction.java
LabelEndFunction.java
   src/java/org/apache/fop/fo/flow BasicLink.java
BidiOverride.java Block.java BlockContainer.java
Character.java ExternalGraphic.java Float.java
InitialPropertySet.java Inline.java
InlineContainer.java InstreamForeignObject.java
Leader.java ListBlock.java ListItem.java
ListItemBody.java ListItemLabel.java Marker.java
MultiCase.java MultiPropertySet.java
MultiSwitch.java MultiToggle.java PageNumber.java
PageNumberCitation.java RetrieveMarker.java
Table.java TableAndCaption.java TableBody.java
TableCaption.java TableCell.java TableColumn.java
TableRow.java
   src/java/org/apache/fop/fo/pagination ColorProfile.java
ConditionalPageMasterReference.java
PageSequence.java PageSequenceMaster.java
Region.java RegionBA.java RegionBASE.java
RegionBody.java Root.java SimplePageMaster.java
Title.java
   src/java/org/apache/fop/fonts FontSetup.java
   src/java/org/apache/fop/layoutmgr AddLMVisitor.java
BlockContainerLayoutManager.java
PageLayoutManager.java
   src/java/org/apache/fop/render/awt AWTRenderer.java
   src/java/org/apache/fop/render/ps
AbstractPSDocumentGraphics2D.java
AbstractPSTranscoder.java
   src/java/org/apache/fop/render/rtf
ListAttributesConverter.java RTFHandler.java
TableAttributesConverter.java
TextAttributesConverter.java
  Log:
  1. Moved static element and property structures from PropertyList (previously in 
former PropertyListBuilder) to FObj
  
  2. Renamed FObj "properties" instance variable to "propertyList" (reduces
  confusion on the type of object holding FO property information in the code)
  
  3. Unneeded imports removed (Finn Bock's patch, Bug #25582).
  
  Revision  ChangesPath
  1.21  +2 -2  xml-fop/src/codegen/properties.xsl
  
  http://cvs.apache.org/viewcvs/xml-fop/src/codegen/properties.xsl.diff?r1=1.20&r2=1.21
  
  
  1.7   +0 -1  xml-fop/src/java/org/apache/fop/area/AreaTree.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/area/AreaTree.java.diff?r1=1.6&r2=1.7
  
  
  1.22  +34 -13xml-fop/src/java/org/apache/fop/fo/FObj.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FObj.java.diff?r1=1.21&r2=1.22
  
  
  1.17  +1 -1  xml-fop/src/java/org/apache/fop/fo/FObjMixed.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FObjMixed.java.diff?r1=1.16&r2=1.17
  
  
  1.4   +4 -25 xml-fop/src/java/org/apache/fop/fo/PropertyList.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/PropertyList.java.diff?r1=1.3&r2=1.4
  
  
  1.15  +65 -65xml-fop/src/java/org/apache/fop/fo/PropertyManager.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/PropertyManager.java.diff?r1=1.14&r2=1.15
  
  
  1.3   +1 -1  xml-fop/src/java/org/apache/fop/fo/expr/BodyStartFunction.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/expr/BodyStartFunction.java.diff?r1=1.2&r2=1.3
  
  
  1.3   +1 -1  xml-fop/src/java/org/apache/fop/fo/expr/LabelEndFunction.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/expr/LabelEndFunction.java.diff?r1=1.2&r2=1.3
  
  
  1.7   +17 -17xml-fop/src/java/org/apache/fop/fo/flow/BasicLink.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/BasicLink.java.diff?r1=1.6&r2=1.7
  
  
  1.7   +10 -10xml-fop/src/java/org/apache/fop/fo/flow/BidiOverride.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/BidiOverride.java.diff?r1=1.6&r2=1.7
  
  
  1.9   +42 -42xml-fop/src/java/org/apache/fop/fo/flow/Block.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Block.java.diff?r1=1.8&r2=1.9
  
  
  1.7   +19 -19xml-fop/src/java/org/apache/fop/fo/flow/BlockContainer.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/BlockContainer.java.diff?r1=1.6&r2=1.7
  
  
  1.9   +22 -22xml-fop/s

DO NOT REPLY [Bug 25582] - [PATCH] Remove unused imports.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582

[PATCH] Remove unused imports.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-20 06:50 ---
Applied--thanks!

Glen

Re: Suppression of leading space

[J.Pietschmann]

Simon Pepping wrote:
I see no space in the bar inline.
Dumb luck :-). Try:
 
   foo
bar
J.Pietschmann

Re: Suppression of leading space

[Simon Pepping]

On Fri, Dec 19, 2003 at 07:11:57PM +0100, Andreas L. Delmelle wrote:
> > -Original Message-
> > From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> >
> 
> > Anybody dares to interpret how the followung is rendered?
> >   
> > foo
> >  >  font-site="15pt">bar
> > I think this should generate two spaces between  "foo" and "bar".
> >
> 
> One in 10pt, the other 15pt, or 2 spaces of 20pt?

I would think one space before foo according to the characteristics of
the 20pt font and bgcolor red, and one after foo according to the
characteristics of the 10pt font and bgcolor blue. I see no space in
the bar inline.

Regards,
Simon Pepping

-- 
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl

Re: Suppression of leading space

[J.Pietschmann]

Andreas L. Delmelle wrote:
I think this should generate two spaces between  "foo" and "bar".
One in 10pt, the other 15pt, or 2 spaces of 20pt?
Yeah, I deliberately avoided this part of the answer...

So, it would depend on the space-specifiers, which are in this case
unspecified (no borders, no padding, only background --hmm, should that have
an influence? the font-size would IMHO only have an effect in the bp
direction, depending on the alignment-baseline)
So defaults to 0pt (not being inherited by default)
The space constraints probably (hopefully )only applies to
space specifiers on the FOs itself, i.e if I had written
  ...
Space characters ought to be another matter.
That's really a dilemma: you can get rid of most control
characters with FO markup, especially VT, LF and all that,
but there is no way to get rid of spaces. Because of
text-align="justify". Unless leader expansion is better
defined.
J.Pietschmann

Re: AW: What should I be doing ?

[Ben Galbraith]

Do you know other projects dealing with high quality typesetting with
 Java or if Java 1.5 will bring improvements? I'm thinking about
writing my diploma thesis about how to extend the current/implement a
 typesetting API for Java.
The iText project exposes an API for obtaining metrics (including
kerning tables) of a TrueType font (and perhaps Adobe, not sure).  This
information can easily be used to write an algorithm which incorporates
kerning into a custom font rendering pipeline.  I've done it and can
help if need be.
Last time I checked, Java 1.5's slated Java2D changes did not include
this issue.  I for one would love to see better font anti-aliasing and
more font layout controls in the Java2D API.
Let me know if you find anything.  We probably ought to take future
messages on this thread off-line unless some of the FOP developers are
interested in this topic for future FOP work.
Ben

(this message might show up again; I accidentally sent it with another 
account not signed up on the mailing list. Apologies if it does)

Re: Is this a coding flaw ?

[Ben Galbraith]

J.Pietschmann wrote:
That's not the only issue with the Batik bridge - the interface
has been grown for some time.
Anybody out there willing to fix this?
What's wrong with it?  Any functionality broken or is the code just obtuse?

RE: Suppression of leading space

[Andreas L. Delmelle]

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>

> Anybody dares to interpret how the followung is rendered?
>   
> foo
>   font-site="15pt">bar
> I think this should generate two spaces between  "foo" and "bar".
>

One in 10pt, the other 15pt, or 2 spaces of 20pt?

This is the closest in the spec I could find (so far) :

[4.6.1 Stacked Inline Areas]

For a parent area P whose children are inline-areas, P is defined to be
properly stacked if ...

2. For each pair of normal areas I and I' in the subtree below P, if I and
I' have an inline-stacking constraint S, then the distance between the
adjacent edges of I and I' is consistent with the constraint imposed by the
resolved values of the space-specifiers in S.

[a little further up 4.2.5 Stacking Constraints]

Inline-stacking constraints

A and B have an inline-stacking constraint S if ...

3 a. both A and B are inline-areas, B is the next normal sibling area of A,
and S is the sequence consisting of the space-end of A and the space-start
of B

So, it would depend on the space-specifiers, which are in this case
unspecified (no borders, no padding, only background --hmm, should that have
an influence? the font-size would IMHO only have an effect in the bp
direction, depending on the alignment-baseline)
So defaults to 0pt (not being inherited by default)


Cheers,

Andreas

DO NOT REPLY [Bug 25272] - [PATCH] FNF thrown formatting test/resources/fop/image/align.fo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272

[PATCH] FNF thrown formatting test/resources/fop/image/align.fo





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 17:43 ---
On further examination, the command line application uses FOFileHandler to
read FO from a file but embedded apps can use something like the following:

File pdfFile = new File( namePart + ".pdf" );

Driver driver = new Driver();
Logger logger = new ConsoleLogger( ConsoleLogger.LEVEL_INFO ); 
//driver.setLogger( logger );
driver.setRenderer( Driver.RENDER_PDF );
try {
driver.setOutputStream( new java.io.FileOutputStream( pdfFile ) );
Result res = new SAXResult(driver.getContentHandler());
trans2.transform( xmlSource2, res );
}

And Driver sets the ContentHandler to an instance of FOTreeBuilder. So I'll need 
to crawl through some more innards to complete a fix.

New Year's resolution:

To learn as much every day, as I did after making yesterday's tactless remark.
WITHOUT being tactless.

Re: Suppression of leading space

[J.Pietschmann]

Finn Bock wrote:
I was taking a look at the issue where the text in a fo:block has a 
leading space added. I thought that by default, the initial spaces and 
LFs for such a block should be suppressed, but I can't quite find the 
place in the spec where it is defined.
It is not explicitely spelled out anywheree. The common interpretation is
that
1. spaces are suppressed around line *breaks* (not line feed characters)
 for the default value of white-space-treatment
2. the start and end of a block are considered to constitute line breaks
Specifically 1 means you don't get underlined spaces at the end of a
line. If the following
  foo bar
wraps after foo (i.e. there is a line break) the space is suppressed
and you don't get
  foo_
  bar
(with underlined "foo" and "bar")
but
  foo
  bar
(with underlined "foo" and "bar").
Before you ask the other obvious question:
  foo bar
is rendered as
  foo _bar
(with an underlined "bar"). There is a single non-underlined and a single
underlined space between the two (subject to space adjustment). Consecutive
spaces are *not* collapsed if they are "marked" differently (different
text decoration and perhaps different background etc.)
This isn't in the published spec, and unfortunately I couldn't find it
in the errata either, however, it is part of the spec anyway, according to
some w3 list members.
Anybody dares to interpret how the followung is rendered?
 
   foo
   bar
I think this should generate two spaces between  "foo" and "bar".
J.Pietschmann

Re: Is this a coding flaw ?

[J.Pietschmann]

John Austin wrote:
And of course, I missed the fact that the last method in the class
contains a pathological use. To get the name of this class, we create a
parser ?  
That's legacy code from pre-JAXP times. IIRC it is still used
in the Batik bridge. The bridge needs an XML parser to parse
references in the SVG to referencable items in other SVGs.
The most ugly issue is mainly how to treat
  gradient="url('#foo')"
stuff in embedded SVG code: #foo could in principle refer to
an unresolvable node at the time it is needed because it is in
another embedded code snippet further down the tree. FOP treats
this as an error, embedded SVGs have to be self-contained. The
spec is not helpful for guidance here.
That's not the only issue with the Batik bridge - the interface
has been grown for some time.
Anybody out there willing to fix this?

RE: Suppression of leading space

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>


> In this case, there will never remain a single space as the result of the
> second step.
>

Which would, of course be a problem in case the space resulting from the
linefeed *does* need to be preserved...

(didn't quite think of that)


Cheers,

Andreas

RE: Suppression of leading space

[Andreas L. Delmelle]

> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
>
> , the text contains:
>
>  0x0a 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x54 0x68 0x69 0x73 ...
>
> the spaces surrounding the LF should be ignores:
>
>  0x0a 0x54 0x68 0x69 0x73 ...
>
> and the linefeed turned into a space:
>
>  0x20 0x54 0x68 0x69 0x73 ...
>
> and last, two or more consecutive spaces removed:
>
>  0x20 0x54 0x68 0x69 0x73 ...
>
> which is exactly what HEAD does!
>
> But surely that can't be right. I must be missing or misreading something.
>

Depends on what is being meant by 'removal' in the last step above, and
'ignoring' in the first...?

Juggling a bit, I think the only way to achieve the desired result is to
'replace' spaces surrounded by a LF by one space, then perform the steps :

- two, or more consecutive spaces 'ignored':

0x0a 0x20 0x54 ...

- turn the linefeed into a space

0x20 0x20 0x54 ...

- consecutive spaces 'removed'

0x54 ...

In this case, there will never remain a single space as the result of the
second step.


Hope this gets you on track!

Cheers,

Andreas

RE: FOs and Areas

[Andreas L. Delmelle]

> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> 
> J.Pietschmann wrote:
> > 
> > I've got a lot of ideas myself, perhaps too many. What the
> > project needs is *working* *code*.
> 
> Working code is predicated on working ideas, is it not?  That's why I 
> asked about ideas.
> 

Not necessarily (--that, I believe, is Victor's whole point). You can have perfectly 
working software, which turns out to be poorly designed, and the biggest problem there 
is that the flaws in the design will almost always turn up at a moment when it's least 
convenient to change it (we'll leave the name-dropping to _your_ imagination ;) )


Cheers,

Andreas

Re: Is this a coding flaw ?

[Ben Galbraith]

John Austin wrote:
Nothing to do with optimization. Just noticed some wrongness
that has the possibility to be pathological wrongness. Classes
should preclude the possibility of erroneous use. The subject
was making a URL resolver thread-safe. The class in question is
a source of state information needed later by the resolver.
Whoops!  Was unsure about butting in the first place, certainly don't 
mean to offend.  But since I already have, let me keep going and explain 
myself.  :-)

The method is not necessarily pathological, right?  If the intent of the 
method is to provide both a convenience method and a point of 
centralization (in case the parser is in the future overridden via one 
of the steps in the SAXParserFactory resolution mechanism or a 
hard-coded instance class name), it certainly has done so.  It's 
legitimate for an app to want to know the class name of the SAX parser 
that will be produced by the app at any given moment.

Hence, since the method's existence has the potential to be legitimate 
(without checking its usages its impossible to know the exact contract 
since it is not documented), I assumed you were concerned with the 
performance implications of working around possible thread unsafety.

So, since SAXParserFactory is *not* thread-safe, the createParser() 
method ought to be synchronized and only if the synchronization presents 
a measurably unacceptable latency should caching mechanisms be 
considered (IMHO).

These are the thoughts that led to my earlier message, at least, feeble 
though they are.  ;-)

Ben



[Lucky thing we didn't mention the dirty knife!]

On Fri, 2003-12-19 at 11:50, Ben Galbraith wrote:

Jeremias Maerki wrote:

Hmm, again, we could probably cache the value. Not very elegant, of
course, but how else do we get that value which is used in several
places?
Just an outsider's point-of-view: it probably doesn't make sense to 
waste time optimizing code like this unless a profiler indicates that 
it's a bottleneck.

Randomly searching through code for potential inefficiencies has widely 
been disproven as an effective optimization technique.  ;-)

Ben


On 19.12.2003 13:57:26 John Austin wrote:


And of course, I missed the fact that the last method in the class
contains a pathological use. To get the name of this class, we create a
parser ?  

 /**
   * Returns the fully qualified classname of the standard XML parser
for FOP
   * to use.
   * @return the XML parser classname
   */
  public static final String getParserClassName() {
  try {
  return createParser().getClass().getName();
  } catch (FOPException e) {
  return null;
  }
  }


Jeremias Maerki

RE: FOs and Areas

[Andreas L. Delmelle]

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
> Yuck! Flashbacks of SoftRAM
>

Ok, that's understood! None of that here!

Thanks for the info. (I'll be back with more ideas... maybe some more bad
ones, but I'll leave you guys to judge that ;) )

Cheers,

Andreas

Re: Is this a coding flaw ?

[John Austin]

Nothing to do with optimization. Just noticed some wrongness
that has the possibility to be pathological wrongness. Classes
should preclude the possibility of erroneous use. The subject
was making a URL resolver thread-safe. The class in question is
a source of state information needed later by the resolver.

[Lucky thing we didn't mention the dirty knife!]

On Fri, 2003-12-19 at 11:50, Ben Galbraith wrote:
> Jeremias Maerki wrote:
> > Hmm, again, we could probably cache the value. Not very elegant, of
> > course, but how else do we get that value which is used in several
> > places?
> 
> Just an outsider's point-of-view: it probably doesn't make sense to 
> waste time optimizing code like this unless a profiler indicates that 
> it's a bottleneck.
> 
> Randomly searching through code for potential inefficiencies has widely 
> been disproven as an effective optimization technique.  ;-)
> 
> Ben
> 
> > 
> > On 19.12.2003 13:57:26 John Austin wrote:
> > 
> >>And of course, I missed the fact that the last method in the class
> >>contains a pathological use. To get the name of this class, we create a
> >>parser ?  
> >>
> >>   /**
> >> * Returns the fully qualified classname of the standard XML parser
> >>for FOP
> >> * to use.
> >> * @return the XML parser classname
> >> */
> >>public static final String getParserClassName() {
> >>try {
> >>return createParser().getClass().getName();
> >>} catch (FOPException e) {
> >>return null;
> >>}
> >>}
> > 
> > 
> > 
> > Jeremias Maerki
> > 
-- 
John Austin <[EMAIL PROTECTED]>

Re: Is this a coding flaw ?

[Ben Galbraith]

Jeremias Maerki wrote:
Hmm, again, we could probably cache the value. Not very elegant, of
course, but how else do we get that value which is used in several
places?
Just an outsider's point-of-view: it probably doesn't make sense to 
waste time optimizing code like this unless a profiler indicates that 
it's a bottleneck.

Randomly searching through code for potential inefficiencies has widely 
been disproven as an effective optimization technique.  ;-)

Ben

On 19.12.2003 13:57:26 John Austin wrote:

And of course, I missed the fact that the last method in the class
contains a pathological use. To get the name of this class, we create a
parser ?  

  /**
* Returns the fully qualified classname of the standard XML parser
for FOP
* to use.
* @return the XML parser classname
*/
   public static final String getParserClassName() {
   try {
   return createParser().getClass().getName();
   } catch (FOPException e) {
   return null;
   }
   }


Jeremias Maerki

Suppression of leading space

[Finn Bock]

Hi,

I was taking a look at the issue where the text in a fo:block has a 
leading space added. I thought that by default, the initial spaces and 
LFs for such a block should be suppressed, but I can't quite find the 
place in the spec where it is defined.

At least 3 properties comes into play:

white-space-treatment (default: ignore-if-surrounding-linefeed)
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#white-space-treatment
linefeed-treatment  (default: treat-as-space)
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#linefeed-treatment
white-space-collapse (default: true)
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#white-space-collapse
For an example like this:


This is a simple fo block.

, the text contains:

0x0a 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x54 0x68 0x69 0x73 ...

the spaces surrounding the LF should be ignores:

0x0a 0x54 0x68 0x69 0x73 ...

and the linefeed turned into a space:

0x20 0x54 0x68 0x69 0x73 ...

and last, two or more consecutive spaces removed:

0x20 0x54 0x68 0x69 0x73 ...

which is exactly what HEAD does!

But surely that can't be right. I must be missing or misreading something.

regards,
finn

Re: Is this a coding flaw ?

[Jeremias Maerki]

Hmm, again, we could probably cache the value. Not very elegant, of
course, but how else do we get that value which is used in several
places?

On 19.12.2003 13:57:26 John Austin wrote:
> And of course, I missed the fact that the last method in the class
> contains a pathological use. To get the name of this class, we create a
> parser ?  
> 
>/**
>  * Returns the fully qualified classname of the standard XML parser
> for FOP
>  * to use.
>  * @return the XML parser classname
>  */
> public static final String getParserClassName() {
> try {
> return createParser().getClass().getName();
> } catch (FOPException e) {
> return null;
> }
> }


Jeremias Maerki

DO NOT REPLY [Bug 25272] - [PATCH] FNF thrown formatting test/resources/fop/image/align.fo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272

[PATCH] FNF thrown formatting test/resources/fop/image/align.fo





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 14:05 ---
Feedback accepted.

The only place that needs to change to fix this problem, is the
ImageFactory method:
protected static InputStream openStream(String href, FOUserAgent ua)

The current state of the input stream is set in the constructors of
FOFileHandler which is called normally from CommandLineOptions and 
a couple of other less critical places.

Also, FOUserAgent hold a reference to a logger and there is a bit of code that 
needs to have logging support added. So I shall amend my suggested fix.

Re: Is this a coding flaw ?

[John Austin]

On Fri, 2003-12-19 at 10:02, Jeremias Maerki wrote:
> I should be thread-safe, the way it is used here. You could of course,
> cache the SAXParserFactory instance but I doubt the performance
> improvement would be measurable. getParser is probably not the best name
> if you look at it from a bean-oriented angle but it's not that it's
> called many times anyway. Do you think we should rename it?
> 
> On 19.12.2003 13:13:45 John Austin wrote:
> > I found the following snippet in the class FOFileHandler:

And of course, I missed the fact that the last method in the class
contains a pathological use. To get the name of this class, we create a
parser ?  

   /**
 * Returns the fully qualified classname of the standard XML parser
for FOP
 * to use.
 * @return the XML parser classname
 */
public static final String getParserClassName() {
try {
return createParser().getClass().getName();
} catch (FOPException e) {
return null;
}
}

-- 
John Austin <[EMAIL PROTECTED]>

Re: Is this a coding flaw ?

[John Austin]

On Fri, 2003-12-19 at 10:02, Jeremias Maerki wrote:
> I should be thread-safe, the way it is used here. You could of course,
> cache the SAXParserFactory instance but I doubt the performance
> improvement would be measurable. getParser is probably not the best name
> if you look at it from a bean-oriented angle but it's not that it's
> called many times anyway. Do you think we should rename it?

As long as we are certain that it is being used correctly, probably
not necessary. Just jumped a bit when I saw the possibility that it
would be easily mis-used.

> 
> On 19.12.2003 13:13:45 John Austin wrote:
> > I found the following snippet in the class FOFileHandler:
> > 
> > ===
> > /**
> >  * @see org.apache.fop.apps.InputHandler#getParser()
> >  */
> > public XMLReader getParser() throws FOPException {
> > return createParser();
> > }
> > ===
> > 
> > and the createParser() method
> > 
> > ===
> > /**
> >  * Creates XMLReader object using default
> >  * SAXParserFactory
> >  * @return the created XMLReader
> >  * @throws FOPException if the parser couldn't be created or
> > configured for proper operation.
> >  */
> > protected static XMLReader createParser() throws FOPException {
> > try {
> > SAXParserFactory factory = SAXParserFactory.newInstance();
> > factory.setNamespaceAware(true);
> > factory.setFeature(
> > "http://xml.org/sax/features/namespace-prefixes";, true);
> > return factory.newSAXParser().getXMLReader();
> > 
> > 
> > 
> > ===
> > 
> > Now it would seem to me that a 'getter' method should not go around 
> > creating objects every time it needs to. It hust doesn't look right.
> > 
> > I assume that SAXParserFactory is thread-safe.
> 
> 
> Jeremias Maerki
-- 
John Austin <[EMAIL PROTECTED]>

Re: Is this a coding flaw ?

[Jeremias Maerki]

I should be thread-safe, the way it is used here. You could of course,
cache the SAXParserFactory instance but I doubt the performance
improvement would be measurable. getParser is probably not the best name
if you look at it from a bean-oriented angle but it's not that it's
called many times anyway. Do you think we should rename it?

On 19.12.2003 13:13:45 John Austin wrote:
> I found the following snippet in the class FOFileHandler:
> 
> ===
> /**
>  * @see org.apache.fop.apps.InputHandler#getParser()
>  */
> public XMLReader getParser() throws FOPException {
> return createParser();
> }
> ===
> 
> and the createParser() method
> 
> ===
> /**
>  * Creates XMLReader object using default
>  * SAXParserFactory
>  * @return the created XMLReader
>  * @throws FOPException if the parser couldn't be created or
> configured for proper operation.
>  */
> protected static XMLReader createParser() throws FOPException {
> try {
> SAXParserFactory factory = SAXParserFactory.newInstance();
> factory.setNamespaceAware(true);
> factory.setFeature(
> "http://xml.org/sax/features/namespace-prefixes";, true);
> return factory.newSAXParser().getXMLReader();
> 
> 
> 
> ===
> 
> Now it would seem to me that a 'getter' method should not go around 
> creating objects every time it needs to. It hust doesn't look right.
> 
> I assume that SAXParserFactory is thread-safe.


Jeremias Maerki

Is this a coding flaw ?

[John Austin]

I found the following snippet in the class FOFileHandler:

===
/**
 * @see org.apache.fop.apps.InputHandler#getParser()
 */
public XMLReader getParser() throws FOPException {
return createParser();
}
===

and the createParser() method

===
/**
 * Creates XMLReader object using default
 * SAXParserFactory
 * @return the created XMLReader
 * @throws FOPException if the parser couldn't be created or
configured for proper operation.
 */
protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
factory.setFeature(
"http://xml.org/sax/features/namespace-prefixes";, true);
return factory.newSAXParser().getXMLReader();



===

Now it would seem to me that a 'getter' method should not go around 
creating objects every time it needs to. It hust doesn't look right.

I assume that SAXParserFactory is thread-safe.


-- 
John Austin <[EMAIL PROTECTED]>

DO NOT REPLY [Bug 25272] - [PATCH] FNF thrown formatting test/resources/fop/image/align.fo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272

[PATCH] FNF thrown formatting test/resources/fop/image/align.fo





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 11:54 ---
Singleton was selected because the state needs a place to live. If there is
a logical home for the state information that is thread-safe, that is the place
to put it. I'll have a look at that on the weekend. 

As to the use of the commons or avalon resolvers, I don't mind either approach
but it brings the phrase 'not invented here' to mind. They probably work better
than 
the core Java class but they add to the learning curve.

("Lucky we didn’t say anything about the dirty knife.").

Re: AW: What should I be doing ?

[Christian Ziesemer]

Am Mi, den 17.12.2003 schrieb J.U. Anderegg um 07:53:

> o Java supports TrueType, OPI and Type1 fonts
> o XSL properties : Java TextAttribute's = 1:1
> - TextAttribute maps give a binary object representation for XSL font
> properties in Java (more Float's than int's)
> - Java2D 1.4 does not process stretch and weight properly (hopefully fixed
> in Java 1.5), variant is not supported
> - font face picking by Java 1.4 is funny: a static font mapping is required
> to get predictable results
> o Java2D supports font metrics, i18n, bidi and Unicode well
> o Java2D does not support
> - word and character spacing: may be programmed by inserting white space
> - kerning: info not available in font metrics

Do you know other projects dealing with high quality typesetting with
Java or if Java 1.5 will bring improvements? I'm thinking about writing
my diploma thesis about how to extend the current/implement a
typesetting API for Java.

Christian

DO NOT REPLY [Bug 25646] - [PATCH] line and column numbers on fo:elements

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25646

[PATCH] line and column numbers on fo:elements





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 10:34 ---
Created an attachment (id=9637)
A unified diff against HEAD.

DO NOT REPLY [Bug 25646] New: - [PATCH] line and column numbers on fo:elements

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25646

[PATCH] line and column numbers on fo:elements

   Summary: [PATCH] line and column numbers on fo:elements
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch assign line and column number values to the already existing fields 
in FObj and adds a simple toString() method to FObj.

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java

[Finn Bock]

Also, while I used fo:element constants in my
experiment, it is clear to 
me that such an approach does not work well for
extension elements.
[Glen Mazza]

Oh no--I hope you don't mean we have to revert to
strings for those?  
No, not at all. It is just that the element id's for extensions must be 
assigned dynamically. Something along the lines of:

in FONode (or anywhere else):

private static int _elementId = Constants.ELEMENT_COUNT;
synchronized public static int makeElementIdentifier() {
return ++_elementId;
}
and in each and every extension subclass of FONode this boilerplate:

private static int elementId = makeElementIdentifier();
public int getElementId() {
return elementId;
}
Using that logic, property
constants wouldn't work either, right?  (because
extension elements can have different properties).
At the moment, my performance experiment does not support extension 
properties either, but it can be added like this:

- An API that allow the extension to assign values to its property 
identifiers dynamically, like elementId above.
- An API that allow the extension to inserts its properties into the 
bitset of the parent elements. Otherwise extension property values can 
not be inherited from the normal fo: elements. (BTW, this is a good 
argument for calculating the full inheritance bitset at runtime).

A change to int elementId's and properties along the lines of my 
experiment, would mean a somewhat higher burden on extension writers.

regards,
finn

Fw: XSL 1.1 RD and first WD have been published

[Jeremias Maerki]

For those who didn't see it:

Forwarded by Jeremias Maerki <[EMAIL PROTECTED]>
--- Original Message ---
 From:Paul Grosso <[EMAIL PROTECTED]>
 To:  [EMAIL PROTECTED]
 Date:Wed, 17 Dec 2003 09:35:19 -0600
 Subject: XSL 1.1 RD and first WD have been published



The XSL Working Group would like to announce the publication 
of the first working draft of:
  Extensible Stylesheet Language (XSL) Version 1.1 Requirements
and
  Extensible Stylesheet Language (XSL) Version 1.1

The documents are available at:
  http://www.w3.org/TR/2003/WD-xsl11-req-20031217
and
  http://www.w3.org/TR/2003/WD-xsl11-20031217

Here is an excerpt from the Abstract of the RD that explains
the general scope of XSL 1.1:

 Since becoming a Recommendation on 15 October 2001, XSL 1.0 has enjoyed 
 widespread support. However, the user community has expressed requirements 
 that have encouraged various implementations to provide extensions to the 
 language. These extensions--especially those implemented by more than one 
 implementation--are clear candidates for standardization so as to maximize 
 interoperability.

 The XSL Working Group has surveyed and analyzed various existing extensions, 
 user requirements, and features intentionally cut from XSL 1.0 due to lack 
 of time. Using the results of this research, the Working Group is developing 
 an XSL 1.1 version that incorporates current errata and includes a subset of 
 relatively simple and upward compatible additions to XSL.

See the RD for a more specific list of features expected to be
addressed in XSL 1.1.

Comments on these drafts are invited from W3C members and the
interested public--see the drafts for details.

paul 

Paul Grosso for the XSL FO Subgroup of the XSL WG

- Original Message Ends 


Jeremias Maerki

DO NOT REPLY [Bug 25272] - [PATCH] FNF thrown formatting test/resources/fop/image/align.fo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25272

[PATCH] FNF thrown formatting test/resources/fop/image/align.fo





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 07:18 ---
Sorry to come in late on this but I see a problem with the proposed changes: 
They don't work in a multi-threaded environment. One of the goals in the 
transition from the old maintenance branch to the redesign is get rid of as 
many statics as possible to avoid any multi-threading problems.

URL resolution would better be done through the Document class (there's one 
for each currently rendered document) or through the FOUserAgent although the 
latter is configuration-dependant and not "run"-dependant (as Document is).

Another important thing to respect in this context is the proper resolution of 
URIs. We should be able to make use of an XML Resolver 
(http://xml.apache.org/commons/components/resolver/index.html) and the whole 
thing should be easily pluggable into Cocoon (which uses Avalon's 
SourceResolver concept, http://avalon.apache.org/excalibur/sourceresolve-
index.html).