DO NOT REPLY [Bug 20411] - German hyphenation is ^H^H^Hwas missing

[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=20411

German hyphenation is ^H^H^Hwas missing

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 13:20 ---
We've had german hyphenation files in FOP earlier but had to remove them 
because of license issues. See Release Notes 
(http://xml.apache.org/fop/relnotes.html).

Unfortunately, your hyphenation file is based on a file released under the 
LPPL which is considered incompatible with the ASL. Therefore, we can't accept 
your contribution. I'm sorry. I've recently updated the documentation on this 
topic (http://xml.apache.org/fop/configuration.html). If the LPPL works for 
your environment, fine. You can even publish the file yourself as long as you 
respect the license of the original file. But Apache can't redistribute that 
file.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Area Tree vs. subsequent renderer (was Re: FO property expressions)

[Jeremias Maerki]

Peter's right. We've done some loud thinking a few months back (Dec/Jan,
I think) about the possibility to create several output files from the
same area tree. At the moment anyway, the renderer provides the fonts
and the layout engine adjusts to that. So, that means that the area tree
differs depending on the renderer used. That can be improved but only by
making a central font registry. The renderer would then announce which
font sources it supports. It's all in the archives.

On 02.06.2003 14:27:07 Peter B. West wrote:
> > For those output formats requiring an area tree (i.e.,
> > non-TXT, RTF, etc.), the area tree is independent of
> > the renderer, correct?
> > 
> > I.e., the area tree created for a document will be 
> > the same for all renderers, and the area tree is
> > created without taking into account its subsequent
> > renderer.
> 
> In general, no.  Most of the atoms composing the area tree are character 
> glyphs.  How they are composed on the page depends on their metrics. 
> The font metrics may vary from renderer to renderer.  For this reason, 
> the target renderer (or at the very least the font metrics associated 
> with the renderer) must be known.  Jeremias, Victor and others have been 
> concerned with factoring out a fonts subsystem, so they may be able to 
> promise that for FOP this issue will be resolved.
> 
> I know nothing at all about image rendering, but there may also be 
> renderer dependencies in the composition of images.



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [GUMP] Build Failure - xml-fop

[Jeremias Maerki]

On 02.06.2003 14:12:43 Thomas E Deweese wrote:
> > "JM" == Jeremias Maerki <[EMAIL PROTECTED]> writes:
> 
> JM> However, I'm worrying about binary compatibility. At the moment we
> JM> have to tell our users that they have to use the Batik-version
> JM> delivered with FOP. I'd like to see Batik's API stabilize some
> JM> more so people can just download the latest version of Batik and
> JM> replace it in their installation. I realize that FOP is a somehat
> JM> special Batik customer from an API-POV. But let's take Cocoon: It
> JM> contains blocks for Batik and FOP (where FOP uses Batik for SVG
> JM> support). If a Cocoon user needs to use Batik (for generating SVG)
> JM> and FOP (for generating PDF containing SVG graphics) this user is
> JM> constrained to use the Batik version that FOP was compiled
> JM> with. He cannot simply upgrade his Batik version to avoid a bug,
> JM> for example. The very least he has to do is recompile FOP with
> JM> that specific version of Batik he wants to use. Hopefully it
> JM> compiles. To illustrate:
> 
> Clearly having no interfaces change is a good thing, but we also
> need to support SVG properly - the equivalent of this change was
> _required_ to properly support SVG.  It could have been done other
> ways that (I think) would have preserved binary compatibility but they
> would have had significant drawbacks on performance, maintainability
> and robustness.

I understand. We have similar problems with the transition from
maintenance branch to redeign.

> FOP is a special customer and I am actually quite
> surprised that you are creating subclasses of GraphicsNode (I
> understand what is being done there but I could have suggested a
> couple of 'better' ways to do it I think).

Well, it's the way it is done now. It would be great if you could
outline better ways to do what we need to do.

> JM> As I said before, the FOP teams "produced" similar problems in the
> JM> past.  After a recent problem between Cocoon and FOP I'm committed
> JM> to watching over FOP's APIs. I'm hoping that the Batik team will
> JM> similarly watch over what happens in their APIs.
> 
> So you are now committed to not introducing any binary or source
> incompatibilities?

I want to avoid them where possible. I want to help making sure that
everyone thinks twice before changing an API. I'm not going to stand in
the way of change. But we always have to be aware of our customers' needs.

> I don't think Batik is in a position to do this
> yet.  I would say that when 1.5 goes final we might be willing to
> offer that assurance for releases in the '1.5' branch.  But we still
> need at some point to support SMIL Animation I can guarantee you that
> this will involve incompatible API changes/extensions/etc.

Sounds to me like some problems could be avoided by separating
non-interactive and interactive APIs. Like subclassing
AbstractGraphicsNode to AbstractInteractiveGraphicsNode (which contains
the getSensitiveBound() method). Just a thought, I'm not familiar enough
with Batik.

> >> BTW perhaps I'm missing the point of the 'maintence' build but
> >> shouldn't that be done off one of the release versions of Batik?
> 
> JM> I'm under the impression that Gump is intended to check
> JM> code-compatibility between projects in CVS, not against released
> JM> versions. This is to have an early warning about incompatible
> JM> changes (before a release), so they can be resolved (hopefully
> JM> with a compatibility layer) before the release.
> 
> I guess as long as you can still make changes in the 'maintence'
> branch it isn't an issue - but I would have thought that a particular
> version of Batik would have already been targeted for the release of
> FOP - rather than tracking 'HEAD'.  It just seems odd to me that a
> 'stable' version of FOP would track 'HEAD' on Batik.

Not really stable. :-) The branch is more than 20 months old and has
seen very active development. It's really two development tracks like
Xalan 1 and 2. The older gets discarded eventually.

> JM> With my findings above I think it would even make sense to have an
> JM> additional mechanism to check binary compatibility (just some
> JM> runtime tests using JUnit, for example) between projects (CVS of
> JM> project 1 against release xy of project 2).
> 
> Binary compatibility is really, really hard to ensure and I think
> it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be
> binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and
> 1.5b5 do not need to be) - all of course IMHO - other Batik developers
> may (and probably will :) disagree.

Batik's in beta mode, FOP's in release candidate modefor a very long
time. :-) That basically makes each beta/rc releases quite important.
But you're right, except that I would expect compatibility over a full
version (1.x).

I think you're missing my point about that idea: Testing a project CVS
against dependent releases may be a good way to make a deve

Re: Area Tree vs. subsequent renderer (was Re: FO property expressions)

[Peter B. West]

Glen Mazza wrote:
Thanks, Peter, for the explanation on the
property/inheritance computations--I have one more
question, perhaps anyone can answer (The Area
Tree/Renderer explanations on the Design Tab is
somewhat vague on this point):  

For those output formats requiring an area tree (i.e.,
non-TXT, RTF, etc.), the area tree is independent of
the renderer, correct?
I.e., the area tree created for a document will be 
the same for all renderers, and the area tree is
created without taking into account its subsequent
renderer.
Glen,

In general, no.  Most of the atoms composing the area tree are character 
glyphs.  How they are composed on the page depends on their metrics. 
The font metrics may vary from renderer to renderer.  For this reason, 
the target renderer (or at the very least the font metrics associated 
with the renderer) must be known.  Jeremias, Victor and others have been 
concerned with factoring out a fonts subsystem, so they may be able to 
promise that for FOP this issue will be resolved.

I know nothing at all about image rendering, but there may also be 
renderer dependencies in the composition of images.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [GUMP] Build Failure - xml-fop

[Thomas E Deweese]

> "JM" == Jeremias Maerki <[EMAIL PROTECTED]> writes:

JM> However, I'm worrying about binary compatibility. At the moment we
JM> have to tell our users that they have to use the Batik-version
JM> delivered with FOP. I'd like to see Batik's API stabilize some
JM> more so people can just download the latest version of Batik and
JM> replace it in their installation. I realize that FOP is a somehat
JM> special Batik customer from an API-POV. But let's take Cocoon: It
JM> contains blocks for Batik and FOP (where FOP uses Batik for SVG
JM> support). If a Cocoon user needs to use Batik (for generating SVG)
JM> and FOP (for generating PDF containing SVG graphics) this user is
JM> constrained to use the Batik version that FOP was compiled
JM> with. He cannot simply upgrade his Batik version to avoid a bug,
JM> for example. The very least he has to do is recompile FOP with
JM> that specific version of Batik he wants to use. Hopefully it
JM> compiles. To illustrate:

Clearly having no interfaces change is a good thing, but we also
need to support SVG properly - the equivalent of this change was
_required_ to properly support SVG.  It could have been done other
ways that (I think) would have preserved binary compatibility but they
would have had significant drawbacks on performance, maintainability
and robustness.  FOP is a special customer and I am actually quite
surprised that you are creating subclasses of GraphicsNode (I
understand what is being done there but I could have suggested a
couple of 'better' ways to do it I think).

JM> As I said before, the FOP teams "produced" similar problems in the
JM> past.  After a recent problem between Cocoon and FOP I'm committed
JM> to watching over FOP's APIs. I'm hoping that the Batik team will
JM> similarly watch over what happens in their APIs.

So you are now committed to not introducing any binary or source
incompatibilities?  I don't think Batik is in a position to do this
yet.  I would say that when 1.5 goes final we might be willing to
offer that assurance for releases in the '1.5' branch.  But we still
need at some point to support SMIL Animation I can guarantee you that
this will involve incompatible API changes/extensions/etc.

>> BTW perhaps I'm missing the point of the 'maintence' build but
>> shouldn't that be done off one of the release versions of Batik?

JM> I'm under the impression that Gump is intended to check
JM> code-compatibility between projects in CVS, not against released
JM> versions. This is to have an early warning about incompatible
JM> changes (before a release), so they can be resolved (hopefully
JM> with a compatibility layer) before the release.

I guess as long as you can still make changes in the 'maintence'
branch it isn't an issue - but I would have thought that a particular
version of Batik would have already been targeted for the release of
FOP - rather than tracking 'HEAD'.  It just seems odd to me that a
'stable' version of FOP would track 'HEAD' on Batik.

JM> With my findings above I think it would even make sense to have an
JM> additional mechanism to check binary compatibility (just some
JM> runtime tests using JUnit, for example) between projects (CVS of
JM> project 1 against release xy of project 2).

Binary compatibility is really, really hard to ensure and I think
it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be
binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and
1.5b5 do not need to be) - all of course IMHO - other Batik developers
may (and probably will :) disagree.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Thoughts on design - FO expressions in markers

[Peter B. West]

Fopdevs,

Further to this topic.

Peter B. West wrote:
Yes, and this whole post was a bit of a disaster. The point I had 
fuzzily in mind was that the resolution of marker properties can only 
occur as the area tree (of the fo:flow) is being constructed.  Only then 
does "current page" have any meaning.  It's an example of the 
impossibility of resolving FO property expressions independently of area 
tree construction.
I have attached a diagram illustrating my thinking about processing 
markers in the context of alt.design.

Fig 1) illustrates the general flow of control in alt.design's pull 
parsing.  FoXMLEvents are pulled from buffer on demand, and processed 
into the FO Tree.

2) shows my original vague idea for handling fo:markers.  Because there 
is no context for resolving fo:marker properties where they are 
encountered in the fo:flow, I was intending to divert the FoXMLEvents 
into named buffers for later processing in a manner parallel to the 
mainstream XML event processing.

3) represents the problem of reconciling a pre-built FO static-content 
sub-tree with a buffer of FoXMLEvents representing the fo:marker, within 
the overall context of the construction of the static region area sub-trees.

4) represents a solution in conjunction with 2).  Viz., divert not only 
the fo:marker subtrees from the fo:flows into FoXMLEvent buffers, but 
also the whole of each fo:static-content subtree.  As Joerg pointed out, 
the size of the static regions is fixed, so they have no impact on the 
layout of the region-body.  (Let me know if I'm missing something here.) 
 Furthermore, if they contain an fo:retrieve-markers, the resolution of 
the static content region is "dymanic" to the extent of the markers 
being retrieved.

The general solution is represented by 5).  The whole of the 
static-content subtree is processed as the area tree for that region is 
being built, and after the region-body has been laid out.  As 
fo:retrieve-markers are encountered in the stream of events, they are 
resolved with reference to the current and previous pages, and the 
appropriate fo:marker buffer becomes the reference for events.  The 
existing mechanism for obtaining events can readily be generalised to 
query the appropriate buffer.  Where a static-content sub-tree has no 
fo:retrieve-markers, the optimisation is obviously to resolve the 
sub-tree once.

The most interesting point here is that the processing of the FO 
sub-tree is driven from within the construction of the relevant area 
sub-tree.  I am increasingly of the opinion that such should be the 
general approach to all FO tree handling - that it should be 
demand-driven by the construction of the area tree.  I haven't 
considered thsi in enough detail to be more definite that that yet.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20411] - German hyphenation is ^H^H^Hwas missing

[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=20411

German hyphenation is ^H^H^Hwas missing





--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 11:08 ---
Created an attachment (id=6595)
Hyphenation file for (new) German orthography

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20411] New: - German hyphenation is ^H^H^Hwas missing

[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=20411

German hyphenation is ^H^H^Hwas missing

   Summary: German hyphenation is ^H^H^Hwas missing
   Product: Fop
   Version: 0.20.5
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have converted a TeX hyphenation file.  The conversion was done by Perl, by vi
and by hand, be prepared for errors.  I have tested it with a document of 50
pages, and haven't found any obvious bugs, however.

The file is (hopefully) attached to the bug report.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[GUMP] Build Failure - xml-fop

[Sam Ruby]

This email is autogenerated from the output from:



Buildfile: build.xml

init-avail:
 [echo] Jimi Support NOT Present
 [echo] JAI Support NOT Present
 [echo] JCE Support PRESENT

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to /home/rubys/jakarta/xml-fop/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 1.0dev [1999-2003] 
 [echo] See build.properties and build-local.properties for additional build 
settings
   [filter] Reading filters from /home/rubys/jakarta/xml-fop/build/src/codegen/filter

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/gensrc
[mkdir] Created dir: 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fo/properties
[mkdir] Created dir: 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14
[mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/hyph

codegen:
 [echo] Resetting codegen directory
 [copy] Copying 33 files to /home/rubys/jakarta/xml-fop/build/src/codegen
 [echo] Generating the java files from xml resources
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/allprops.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fo/properties/Constants.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/genconst.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml 
to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fo/properties/fo_ignore_this.dummy
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/properties.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml 
to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fo/properties/FOPropertyMapping.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/propmap.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml 
to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fo/properties/foenums_ignore_this.dummy
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/enumgen.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/encodings.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/CodePointMapping.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/code-point-mapping.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/Courier.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/Courier.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop/build/src/codegen/CourierOblique.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/CourierOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/CourierBold.xml 
to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/CourierBold.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop/build/src/codegen/CourierBoldOblique.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/CourierBoldOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/Helvetica.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/Helvetica.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/HelveticaBold.xml 
to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaBold.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop/build/src/codegen/HelveticaOblique.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop/build/src/codegen/HelveticaBoldOblique.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/org/apache/fop/fonts/base14/HelveticaBoldOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/TimesRoman.xml to 
/home/rubys/jakarta/xml-fop/build/gensrc/o

[GUMP] Build Failure - xml-fop-maintenance

[Sam Ruby]

This email is autogenerated from the output from:



Buildfile: build.xml

init-avail:

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to /home/rubys/jakarta/xml-fop-maintenance/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 0.20.5rc3a [1999-2003] 
   [filter] Reading filters from 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/filter

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/fo/properties
[mkdir] Created dir: 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts
[mkdir] Created dir: 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/svg
[mkdir] Created dir: /home/rubys/jakarta/xml-fop-maintenance/build/classes/conf
[mkdir] Created dir: /home/rubys/jakarta/xml-fop-maintenance/build/classes/hyph
 [copy] Copying 3 files to 
/home/rubys/jakarta/xml-fop-maintenance/build/classes/conf
 [copy] Replacing: @version@ -> 0.20.5rc3a

codegen:
 [echo] Resetting codegen directory
 [copy] Copying 37 files to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen
 [echo] Generating the java files from xml resources
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/allprops.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/fo/properties/Constants.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/genconst.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/foproperties.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/fo_ignore_this.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/properties.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/foproperties.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/fo/properties/FOPropertyMapping.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/propmap.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/foproperties.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/foenums_ignore_this.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/enumgen.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/extproperties.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/fo/properties/ExtensionPropertyMapping.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/propmap.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/encodings.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/CodePointMapping.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/code-point-mapping.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Courier.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/Courier.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Courier-Oblique.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/CourierOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Courier-Bold.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/CourierBold.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Courier-BoldOblique.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/CourierBoldOblique.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Helvetica.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/Helvetica.java
[style] Loading stylesheet 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/font-file.xsl
[style] Processing 
/home/rubys/jakarta/xml-fop-maintenance/build/src/codegen/Helvetica-Bold.xml to 
/home/rubys/jakarta/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/HelveticaBold.java

Re: [GUMP] Build Failure - xml-fop

[Jeremias Maerki]

Looks like your message simply got stuck in the moderator's queue.

On 30.05.2003 18:17:31 Thomas DeWeeese wrote:
> Jeremias Maerki wrote:
> 
> >Hi Batik-Devs,
> >
> >the latest changes in Batik broke both the maintenance branch and HEAD
> >of FOP:
> >
> >http://cvs.apache.org/builds/gump/2003-05-30/xml-fop.html
> >http://cvs.apache.org/builds/gump/2003-05-30/xml-fop-maintenance.html
> >
> >Is there any possibility to adjust the changes so they don't break
> >third-party dependencies?
> >
> It would be possible to define 
> AbstractGraphicsNode.getSensitiveBounds to return
> what ever AbstractGraphicsNode.getPrimitiveBounds would return, but I 
> would rather leave it as
> an abstract method because just like the other bounds methods people who 
> derive should
> give careful consideration to the proper value to return for the 
> specific type of graphics node
> involved.  The additional method is required for proper support of 
> pointer-events in SVG.

I see your point.

> In this case it is very simple to define the method (it should I 
> think just return getPrimitiveBounds).

That's true and I'm going to do that.

However, I'm worrying about binary compatibility. At the moment we have
to tell our users that they have to use the Batik-version delivered with
FOP. I'd like to see Batik's API stabilize some more so people can just
download the latest version of Batik and replace it in their
installation. I realize that FOP is a somehat special Batik customer
from an API-POV. But let's take Cocoon: It contains blocks for Batik and
FOP (where FOP uses Batik for SVG support). If a Cocoon user needs to
use Batik (for generating SVG) and FOP (for generating PDF containing
SVG graphics) this user is constrained to use the Batik version that FOP
was compiled with. He cannot simply upgrade his Batik version to avoid a
bug, for example. The very least he has to do is recompile FOP with that
specific version of Batik he wants to use. Hopefully it compiles. To
illustrate:

A few minutes ago a took FOP 0.20.5rc3a and put in batik-all.jar (built from
CVS today). It turns out that binary compatibility got broken in March
already:
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/bridge/UnitProcessor.java.diff?r1=1.10&r2=1.11&diff_format=h

I got the following when running FOP (without recompile because this
would have solved the problem):
Exception in thread "main" java.lang.NoSuchMethodError: 
org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/util/UnitProcessor$Context;
at org.apache.fop.svg.SVGElement.layout(SVGElement.java:218)

As I said before, the FOP teams "produced" similar problems in the past.
After a recent problem between Cocoon and FOP I'm committed to watching
over FOP's APIs. I'm hoping that the Batik team will similarly watch
over what happens in their APIs.

> BTW perhaps I'm missing the point of  the 'maintence' build but 
> shouldn't that be done off
> one of the release versions of Batik?

I'm under the impression that Gump is intended to check code-compatibility
between projects in CVS, not against released versions. This is to have
an early warning about incompatible changes (before a release), so they
can be resolved (hopefully with a compatibility layer) before the
release.

With my findings above I think it would even make sense to have
an additional mechanism to check binary compatibility (just some runtime
tests using JUnit, for example) between projects (CVS of project 1
against release xy of project 2).

FOP's maintenance branch is where our latest release candidate
originated. FOP 0.20.5 will also be based on the maintenance branch. The
trunk of the xml-fop CVS module is home of our redesign effort. This is
also the place where you get the PDF transcoder from because that's
where Keiron Liddle has done a lot of refactoring work for the SVG
support. So, we have two lines of development. After the 0.20.5 release
the maintenance branch will be frozen.
More details here: http://xml.apache.org/fop/dev/

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20407] - [PATCH] Configure image caching using the configuration file

[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=20407

[PATCH] Configure image caching using the configuration file





--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 08:24 ---
Created an attachment (id=6593)
Patched files

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20407] New: - [PATCH] Configure image caching using the configuration file

[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=20407

[PATCH] Configure image caching using the configuration file

   Summary: [PATCH] Configure image caching using the configuration
file
   Product: Fop
   Version: all
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Image caching should be made configurable using the config file. Coding the 
FopImageFactory.resetCache() is not a good way controlling the cache.
This patch includes a config.xml file with a new boolean key value 
called "cacheImages" , an improved Configuration.java, providing the 
isImageCacheEnabled method, and a patched FopImageFactory, that handles image 
caching if isImageCacheEnabled is set to true.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Area Tree vs. subsequent renderer (was Re: FO property expressions)

[Glen Mazza]

Thanks, Peter, for the explanation on the
property/inheritance computations--I have one more
question, perhaps anyone can answer (The Area
Tree/Renderer explanations on the Design Tab is
somewhat vague on this point):  

For those output formats requiring an area tree (i.e.,
non-TXT, RTF, etc.), the area tree is independent of
the renderer, correct?

I.e., the area tree created for a document will be 
the same for all renderers, and the area tree is
created without taking into account its subsequent
renderer.

Thanks,
Glen

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Glen,
> 
> Sorry about the late reply, but this has only just
> arrived.  See 
> comments below.
> 



__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: "Team" page

[Glen Mazza]

Looks good -- would you please update my email address
to my "work" address on the team page:
glen.mazza.at.eds.com. (.at. like all the other email
addresses on that page to avoid spam concerns!)

Thanks,
Glen

--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> 
> > My email was meant as a joke--please publish it,
> > especially as I would like to see the other pages
> (in
> > particular the examples page) updated for this
> > weekend.
> 
> Sorry -- the joke went right over my head. I went
> ahead & published the site
> a few minutes ago -- it should be live in about a
> half-hour, IIRC.
> 
> Victor Mote
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email:
> [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20398] - [PATCH] removing org.apache.fop.tools.xslt package

[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=20398

[PATCH] removing org.apache.fop.tools.xslt package





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 20:33 ---
Created an attachment (id=6590)
Diff file for apps/CommandLineOption change needed

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20398] New: - [PATCH] removing org.apache.fop.tools.xslt package

[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=20398

[PATCH] removing org.apache.fop.tools.xslt package

   Summary: [PATCH] removing org.apache.fop.tools.xslt package
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is a "reminder" patch on dropping Xalan J1 support from FOP.  

Discussion Thread:  
http://marc.theaimsgroup.com/?l=fop-dev&m=105352997216365&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=105354543405308&w=2

It involves:

1) Dropping the org.apache.fop.tools.xslt package (cannot supply a patch for 
this).

2) Moving the maintenance branch versions of *both* TraxInputHandler and 
XSLTInputHandler to the trunk branch.  (also cannot patch.)

http://cvs.apache.org/viewcvs.cgi/xml-
fop/src/org/apache/fop/apps/Attic/TraxInputHandler.java?rev=1.5.2.4&content-
type=text/vnd.viewcvs-markup

http://cvs.apache.org/viewcvs.cgi/xml-
fop/src/org/apache/fop/apps/Attic/XSLTInputHandler.java?rev=1.7.2.4&content-
type=text/vnd.viewcvs-markup

3) CommandLineOptions' getInputHandler() needs updating to declare that it may 
throw FOPExceptions. (Divergence between trunk and maintenance branch -- patch 
is supplied for this.)

http://cvs.apache.org/viewcvs.cgi/xml-
fop/src/org/apache/fop/apps/Attic/CommandLineOptions.java.diff?
r1=1.14.2.6&r2=1.14.2.7&diff_format=h

I have done this locally and tested it with embedded/projectteam.xml & 
projectteam2fo.xsl -- it works fine.

Thanks,
Glen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20397] - [PATCH] Move Structure & LayoutHandlers to fo/area packages

[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=20397

[PATCH] Move Structure & LayoutHandlers to fo/area packages





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 19:07 ---
Created an attachment (id=6589)
other changes needed in related files

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20397] - [PATCH] Move Structure & LayoutHandlers to fo/area packages

[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=20397

[PATCH] Move Structure & LayoutHandlers to fo/area packages





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 19:06 ---
Created an attachment (id=6588)
patch:  changes to structure & layout handler needed

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20397] New: - [PATCH] Move Structure & LayoutHandlers to fo/area packages

[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=20397

[PATCH] Move Structure & LayoutHandlers to fo/area packages

   Summary: [PATCH] Move Structure & LayoutHandlers to fo/area
packages
   Product: Fop
   Version: all
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


These patches moves the LayoutHandler and StructureHandler classes from the 
apps package to their more closely related area and fo packages, respectively.  
(Similar to the current placement for MIFHandler and RTFHandler.)  Have 
compiled and tested successfully with simple.fo.

See http://marc.theaimsgroup.com/?l=fop-dev&m=105280427018620&w=2 for basis.  
Also, this change will also be helpful should we move to multiple layout 
handlers (by separating the apps package away from the layout code), which 
Victor & others were leaning towards over the past week.

To patch:

OtherChangesNeededDiff.txt patch contains all-non LH & SH changes needed.

StructLayoutHandlerDiff.txt patch contains LH & SH class changes needed.  (Done 
separately because these need to move to different directories in CVS)

1) Apply both patches in either order.  
2) Move newly patched LayoutHandler to area and StructureHandler to fo packages.
3) Then build the application.

Thanks,
Glen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Bug report for Fop [2003/06/01]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font  |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in |
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly  |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables   |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body  |
| 3497|New|Maj|2001-09-07|id already exists error when using span="all" attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling="uniform" does not work on images...  |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored?  |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG   |
| 4614|New|Maj|2001-11-03|wrap property combined with Chinese   |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5047|Ass|Nor|2001-11-23|Dotted border style is not supported  |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values   |
| 5674|New|Nor|2002-01-03|postscript generated by FOP is missing end command|
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|fi (fi ligature) produces a "sharp"? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render   |
| 6483|New|Nor|2002-02-15|Table, Loop, "footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect   |
| 6929|New|Nor|2002-03-06|Cells border hidden by cells background   |
| 6997|New|Nor|2002-03-09|Row-spanned row data breaks over a page within a c|
| 7140|New|Enh|2002-03-15|page-position attribute set to "last" on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space   |
| 7487|New|Nor|2002-03-26|break-before="page" for table inserts empty page  |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block  |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|F