Re: [Fwd: CMYK Color Images with PDF Renderer]

[Max Berger]

Dear Venkat,

in PDF, we actually try not to do the conversion of color spaces, but
rather (if possible), keep the original color space.

PDF has the possibility to add color space for images, and if a color
space was defined in the original image, AND the image loader was able
to keep the information, the image is written into the PDF with the
color space info attached.

AFAIK, the only image readers able to handle color space correctly are
PNG and JPEG. All other image readers default to RGB.

With JPEG, the image is kept in a raw format, and embedded into the
pdf as-is, without even decoding it fully.

Max

2010/2/15 Venkat Reddy vanukuri.ven...@googlemail.com:
 Hi,

 I am still looking for the response from the fop-dev team regarding the
 attached mail.
 Thanks for your replies in advance.

 Venkat.

 Hi,

 Can anyone know the classes and methods deals with the CMYK colored Images
 for PDF Renderer?

 I want to know, where exactly the conversion taking palce between RGB and
 CMYK color spaces.
 I have already worked with AFP and PS renderers for CMYK colored images,
 these renderers will use ImageEncodingHelper (XMLGraphicsCommons class) to
 render the respective
 document with colored images. I thought the same class (ImageEncodingHelper)
 is not being used for PDF Renderer.

 Can someone give me an idea? where this coversion is taking place?

 Thanks,
 Venkat.

Re: Patching with GIT/SVN (Re: Making MinOptMax Immutable)

[Max Berger]

Hi *,

Vincent Hennebert schrieb:
 Hi,
 
 Looks like Max is busy with more urgent things :-)

Yes, work keeps me occupied most of the time. I was actually just
looking at the patch again, and decided that I am unable to apply it,
because I do cannot verify if the renames are correct, as it affects
some areas I am not familiar with.

 As this patch will affect my future work on the layout engine, I’d like
 to take over the patch review.

Vincent, feel free to do so. I have not assigned the patch to myself as
I could not promise to review it in a decent time.

 In the last half-an-hour I walked myself through all the diffs,
 file-by-file. I must say - except from TextLayoutManager - it is
 possible to understand all changes.

One more thing I noticed: Alex, you are introducing deprecated methods
and then using them. Please either
- don't mark the methods as deprecated, if they are valid helper methods or
- don't use the deprecated methods, but rather use whatever you inted to
replace it with.


Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Patching with GIT/SVN (Re: Making MinOptMax Immutable)

[Max Berger]

Hi Alex,
Hi *,

if you do not yet have FOP developer access, and you are working on a
larger set of problems, please do not submit one large patch - current
committers will not have the time to go through every single change.
Instead, it is much nicer to have a series of small patches.

One option is to use git. There is a current git clone of the FOP source
tree available [1][2]. It also provides help to untangle tangled working
copies [3]. Git lets you produce patches between different individual
changesets [4], and detects if the patches where applied by someone else.

References:
[1] http://wiki.apache.org/general/GitAtApache
[2] git://git.apache.org/fop.git
[3] http://tomayko.com/writings/the-thing-about-git
[4]
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-your-changes

hth

Max

Alexander Kiel schrieb:
 Hi,
 
 a issued a patch for MinOptMax:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=48071
 
 Please read my first comment there and consider my patch :-)
 
 Best Regards
 Alex
 
 On Sun, 2009-10-25 at 23:45 +0100, Alexander Kiel wrote:
 Hi,

 the class MinOptMax has some 800 usages in FOP. It holds a triple of
 values (min, opt, max) of length quantities. 

 It's heavily used during local computations and passing around. It's
 fields are public (whereas the class comment says they are only package
 visible). The public fields (and many methods) make MinOptMax mutable.
 This mutability is used in the computations for sheer performance
 reasons. But this mutability is a big bug attractor in passing around
 situations.

 I don't think that anyone would wonder that an immutable MinOptMax would
 help FOP.

 This refactoring wouldn't be rocket science if all usages of MinOptMax
 would be covered by tests. I just started and found many such uncovered
 sections. I'm very new here and so I simply can't write such tests. So I
 ask you to possible write such tests or remove uncovered code sections.

 As for performance. I would opt for just refactoring all stuff to
 immutable MinOptMax and only introduce an MinOptMaxBuffer if really
 needed.

 With an immutable MinOptMax we can easily remove all TODO's inside
 MinOptMax. The integrity tests (min = opt = max) and we can remove the
 clone method, because it wouldn't be needed anymore.

 I just started the refactoring. All what I need are unit tests.

 Best Regards
 Alex

 


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Checkstyle RedundantThrowsCheck

[Max Berger]

Hi Alex,

DISCLAIMER: These comments are to be seen as purely academic, and may
be complete overkill. For practical purposes, your code is just fine.

Alexander Kiel schrieb:
 In my attachment Tag.java, you can see a variable named value in the
 constuctor and as field. According the rule, the variable in the
 constructor hides the field. But its really the same thing. I even
 assign it in the last line of the constuctor. 

Options to make this code more readable:

- value is a very generic name, and could be reconsidered. What does the
value actually specify? Looking at the detail, it is the int
representation of the tag in little-endian. So I'd propose
intRepresentation instead.

- in your constructor, you use value to build up the intRepresentation.
In this case, I'd use something like intValue

- you have a static method  valueOf(String) and a constructor (byte[]).
Why two different ways of initializing the class?

- The constructor should be made private. If you really need to access
the (byte[]) from within the package, you may provide a static public
method for access.

- This class could be optimized using the flyweight pattern (e.g.
caching the created objects)

- equals would be more readable if you rename tag to otherTag, and use
this.value == otherTag.value

- checkByte also uses value. In this case, you mean byteValue or
charValue.

- why go with toChars creating an array and then using it?
StringBuilder may be the easier solution.

- in the alluppercase and alllowercase methods: You may consider
using Character.isLetter rather than explicitly checking for space and
numbers. Some characters, such as @ (although probably not used) would
otherwise create bugs.

 Another example is the method getEntriesInOffsetOrder() in the attached
 file OffsetTable.java. It is just a getter of entries but it is named
 different.

getEntriesInOffsetOrder returns a sorted version of the entries. So why
not call the variable sortedEntries?

Other notes:
- getEntries does not return the entries attribute. This means you are
confusing internal and external representation. getEntrieValues() could
be a better name.

- since the entries are re-ordered anyways when adding to the map, why
not use a SortedMap (e.g. TreeMap instead)? Then one getEntries method
would suffice.

- you have some default visibility methods and classes, would should be
reconsidered.

 But in most other methods, the parameter you pass is NOT assigned to the
 internal variable, so they actually refer to a different thing, and
 thats where the confusion starts.
 You are absolutely right. In most cases the variable really refers to a
 different thing. The above two examples are the only two cases where I
 violated the HiddenFieldRule in 155 new classes.

Thats good to know :)

 I think this rule ist mostly helpful in order to think about variable
 names. But I also think that here are a few cases where violating this
 rule makes sense. So maybe the rule ist just not smart enough to detect
 the remaining special cases.

If you are really sure you can always temporary disable CHECKSTLYE with

// CHECKSTYLE:OFF
violating code
// CHECKSTYLE:ON

[don't know if we have that in our checkstyle rules or not, I usually
have it there].

Of course, in this case it would be nice to get a notice why checkstyle
was disabled:
// CHECKSTYLE:OFF
// this.value being build-up
int value;
// CHECKSTYLE:ON
...

 Thats the same as with the Javadoc on public things rule. If there
 isn't anything to say about a public thing which will say more than the
 name itself, than I prefer no comment at all. But how should Checkstyle
 detect such cases? 

In most cases there is more information to be transported. For example
the getEntriesInOffsetOrder method. This may be clear to you because
you have written the code, but I first had to think for a while before I
realized what the offsetOrder is. It was easier for me since I saw the
source code. But would I use your class, it would not get it immediately.

 There is a @SuppressWarnings annotation. I don't know if Checkstyle uses
 it. So maybe if we switch to Java 1.5, we could use it. But even than
 this annotation is a lot of clutter. It's a pity that computers can't
 think.

see above

 Best Regards
 Alex

Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Checkstyle RedundantThrowsCheck

[Max Berger]

Hi *,

this rule is usefull in the case where you use common names for
attributes (such as x, or y), and accidentially overwrite them as
parameters. This again comes back to the point of readability.

The same variable name should ALWAYS refer to the same variable / value.

For setters and constructors this makes sense - after all, in each of
these you have a simple assignment, and both variables will carry the
same value.

But in most other methods, the parameter you pass is NOT assigned to the
internal variable, so they actually refer to a different thing, and
thats where the confusion starts.

I know modern IDEs can show you which variable you actually refer to,
but this usually requires selecting the variable or hovering over it,
which you will not do if you are just reading the code trying to
understand it.

However, since we cannot agree to keep the rule, I'll have to be content
with removing it (which is already done).

Max

Alexander Kiel schrieb:
 Hi Max,
 
 Speaking of that, there’s a rule that I would suggest to disable: the
 HiddenFieldCheck. I don’t really see its benefit. It forces to find
 somewhat artificial names for variables, where the field name is exactly
 what I want. Sometimes a method doesn’t have a name following the
 setField pattern, yet still acts as a setter for Field. This rule would
 make sense if we were using a Hungarian-like notation for variables
 (mMember, pParam, etc.), but that’s not the case in FOP.
 WDYT?
 I like the rule, BUT I am ok with an exception for setters and
 constructors (this is IMO a new option in checkstyle 5):
 http://checkstyle.sourceforge.net/config_coding.html#HiddenField
 
 The exclusion of constructors an setters is important. Otherwise we
 would be forced to use some Hungarian-like scope notation.
 
 But why do you think, that this rule is useful at all?
 
 Best Regards
 Alex


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Questionable whether font-shorthand grammar LL(1)

[Max Berger]

Hi *,

I just want to throw in a different idea (you may ignore it if you like):

How about specifing the grammer and using a tool such as JavaCC to
generate the actual parser? This way you could focus more complete
grammer and have to spend less time writing the parser.

JavaCC is BSD license, so we could easily integrate it in the fop build.

Max

2009/9/28 Vincent Hennebert vhenneb...@gmail.com:
 Hi Jonathan,

 Interesting stuff!

 Jonathan Levinson wrote:
 Hi Vincent,

 snip/

 Because font-variant font-style and font-weight can occur in any order,
 I could not (currently) come up with a grammar in which the directing
 sets were disjoint for each non-terminal.  So I was unable to come up
 with an LL(1) grammar.

 For instance, here are two productions of my attempt at a grammar:

 style-variant-weight - variant-weight

 style-variant-weight - variant-style

 In each case, the first set of style-variant-weight shares a common
 element in two different productions, the literal values for variant.
 One needs to look ahead one more token to see if one has a
 variant-weight or a variant-style.

 (I’ll call “modifier” any of the three style, variant, weight
 properties.)
 Taking the ‘normal’ case apart, and since ‘inherit’ is not allowed in
 the shorthand, I think the values for all modifiers are distinct:
 ‘italic’, ‘oblique’, ‘backslant’ for font-style, ‘small-caps’ for
 font-variant, and the various weight values for font-weight.

 Since all modifiers are set to their initial values prior to the
 shorthand parsing, which is ‘normal’ for all three of them, I think we
 can simply ignore any ‘normal’ value found in the string. That is,
 accept it as a legal terminal but not do anything.

 So I don’t think there is any ambiguity any more. What remains to be
 done is to check that the same modifier is not specified more than once
 (that includes checking that ‘normal’ is not specified more than
 3 times). And it’s probably easier to check that at the semantic level
 instead of crafting special grammar rules.


 snip/
 The books and web articles I read only discussed using recursive descent
 when the grammar is LL(1).  I have the feeling that despite the
 ambiguities in the grammar it is almost LL(k) because font-variant and
 font-style and font-weight almost have disjoint values.   It is at least
 LL(3) and I suspect it is LL(6).

 The font-size property has the good idea of not allowing ‘normal’ as
 a value. The ‘normal’ case for modifiers can be ignored as explained
 above. So I think the grammar still is LL(1)


 snip/
 I'm not as convinced as you are that recursive descent parsing or a
 formal bottom-up-parser will make the code simpler rather than more
 complex because of the complexities of a formal grammar.   Of course,
 however complex the grammar, a table-generating tool - like ANTLR - will
 generate code, however complex, which will faithfully reflect the
 inputted grammar.  However, none of the other properties in FOP use a
 table-generating tool like ANTLR - and I'm not sure what the
 consequences would be to FOP of introducing such a tool.  Given the
 complexities of the grammar, I'm sure that a recursive descent parser
 will be quite complex, and if we are going to use a grammar driven
 approach we would be better off with a tool that generates parsers from
 grammars rather than the recursive descent approach.  Also an advantage
 of parser generators is that one doesn't have to rewrite so much code to
 correct a mistake in one's grammar, if one makes a mistake, or if the
 grammar changes.  Recursive descent parsing can pose its own maintenance
 nightmares.

 Using a grammar tool like ANTLR is probably overkill to parse just
 a shorthand property. Moreover the grammar is not likely to change, so
 that reduces its usefulness even more. That said, most properties can
 accept expressions, where such a tool might actually be interesting.
 I don’t know how far FOP goes to supporting expressions in other
 properties.


 The current approach in FOP for font-shorthand is obscurely written but
 strikes me as basically sound.

 1)      One parses from right-to-left using the fact that spaces divide
 tokens

 The problem is that font families can be specified with strings
 containing whitespace, that must be handled in a specific manner and not
 as a terminal delimitation. Otherwise parsing from right to left would
 indeed probably be relatively easy.


 2)      One lets property makers determine whether they apply to a
 token.  Each property maker is a little parser of the token one feeds
 it.  Because the property makers determine whether they apply to a
 token, one can handle the fact that variant, weight and style can occur
 in any order by feeding the current token to each of the property makers
 for font-variant, font-weight, and font-style in turn.  Whatever they
 accept is ipso-facto a font-variant or a font-weight or font-style.

 Just want to let you know I take the problem seriously, and I'm not
 

Re: Questionable whether font-shorthand grammar LL(1)

[Max Berger]

Hi Vincent,


2009/9/29 Vincent Hennebert vhenneb...@gmail.com:
 How about specifing the grammer and using a tool such as JavaCC to
 generate the actual parser? This way you could focus more complete
 grammer and have to spend less time writing the parser.
 That would be the same as using ANTLR. I feel that this is a bit
 overkill for just parsing the font shorthand property, although that may
 prove to be useful for other properties that can accept complex
 expressions.
 That said, JavaCC is an interesting suggestion, I didn’t think of it. If
 a choice had to be made between ANTLR and JavaCC, which one would win?

ANTLR:
- easy to use
- requires runtime linking of jar [1] (a *huge* disadvantage imo)

JavaCC:
- very sparse documentation
- generates standalone java classes

SableCC:
- better documentation
- LGPL (And therefore maybe not feasible, although it would only be
used at compile time and not runtime)

[1] http://beust.com/weblog/archives/000145.html



Max

Re: Checkstyle RedundantThrowsCheck

[Max Berger]

Vincent,


2009/9/29 Vincent Hennebert vhenneb...@gmail.com:
 I started to write my own checkstyle configuration from scratch some
 time ago, enabling everything that looked important to me. But I’d like
 to test it a bit more before submitting it.

Same here. See the checkstyle file for JEuclid as an example.

http://jeuclid.hg.sourceforge.net/hgweb/jeuclid/jeuclid/file/tip/support/build-tools/src/main/resources/jeuclid/checkstyle.xml

 Speaking of that, there’s a rule that I would suggest to disable: the
 HiddenFieldCheck. I don’t really see its benefit. It forces to find
 somewhat artificial names for variables, where the field name is exactly
 what I want. Sometimes a method doesn’t have a name following the
 setField pattern, yet still acts as a setter for Field. This rule would
 make sense if we were using a Hungarian-like notation for variables
 (mMember, pParam, etc.), but that’s not the case in FOP.
 WDYT?

I like the rule, BUT I am ok with an exception for setters and
constructors (this is IMO a new option in checkstyle 5):
http://checkstyle.sourceforge.net/config_coding.html#HiddenField

Max

Re: Checkstyle RedundantThrowsCheck

[Max Berger]

Alex,

The checkstyle checks are historically grown, and are therefore
incomplete. I personally would turn on much more checks for certain
style issues I like. IMO every option set helps deciding a certain
factor. So more the more checks the better :)

(in short: +1 to your changes).

Right now we have 3 checkstyle files: 3.5, 4.0, and 5.0, which also
means the checks would need to be added in all of them (if possible).
Can we remove any of them? I'd volunteer to modify the ant buildfile
to support 5.0.

I'd also vote for dropping 3.5 support, and potentially dropping checkstyle 4.

Max



2009/9/26 Alexander Kiel alexanderk...@gmx.net:
 Hi,

 why didn't our code style allow unchecked exceptions or subclasses of
 thrown exceptions in Javadoc?

 From checkstyle-5.0.xml:

 module name=RedundantThrowsCheck
    property name=allowSubclasses value=false/
    property name=allowUnchecked value=false/
    property name=severity value=warning/
 /module

 From J. Bloch: Effective Java, Second Edition [1] page 252:

Use the Javadoc @thows tag to document each unchecked exception
that a method can throw, but do not use the throws keyword to
include unchecked exceptions in the method declaration.

 Every good code I know, documents unchecked exceptions. Take the Java
 Collections API. Every possible ClassCastException or
 NullPointerException is documented.

 Another quote from J. Bloch:

A well-documented list of unchecked exceptions that a method
can throw effectively describes the preconditions for its
successful execution. It is essential that each method's
documentation describe its preconditions [...]

 I think that everyone can agree with the statements J. Bloch made. So I
 would strongly vote to allow documenting unchecked exceptions.


 The second point is not allowing subclasses of exceptions in Javadoc. I
 don't use this very often, but I have just one example in my mind where
 this makes sense. If you have a look into
 java.io.DataInputStream#readByte(), there are both IOException and
 EOFException documented. EOFException is a subclass of IOException. As
 you know a normal InputStream.read() returns -1 at EOF but readByte()
 doesn't. So it's worth documenting that readByte() is throwing a
 EOFException instead.

 So I would also vote allowing subclasses.


 Best Regards
 Alex

 [1]: http://www.amazon.com/dp/0321356683/

 --
 e-mail: alexanderk...@gmx.net
 web:    www.alexanderkiel.net

Re: Confused about checkstyle use

[Max Berger]

Alex,

2009/9/28 Alexander Kiel alexanderk...@gmx.net:
 Hi Vincent,

 However, new committed code is not supposed to break any rule, neither
 warnings nor errors.

 Really? That means commenting every public method even simple Getters
 and Setters?

Yes. Simple Getter and Setters are the only place where you can
publicly document private variables. (in most cases, comment in the
getter and link from the setter)


 Commenting equals(), hashCode() and toString()? I think,
 this would be only clutter.

/** {...@inheritdoc} */

would do the trick on those,  UNLESS they implement something which is
unexpected (such as the equals methods I recently renamed which did
not implement equals) or special (a toString which creates a
guaranteed parsable result for example)


 Best Regards
 Alex

hth

Max

Re: PDFFontDescriptor Ascent Descent and FontBBox

[Max Berger]

Alexandar,

on a completely different note:

It may be interesting to also look into fontbox (part of pdfbox),
which is now also an apache project, and therefore we could use source
synergy.

http://incubator.apache.org/pdfbox/

For the issue you've mentioned: This may be due so some issues with
CID fonts not properly defining ascent and descent, but I don't have a
reference for it. We would probably need some fonts to test and check.

Max

2009/9/21 Alexander Kiel alexanderk...@gmx.net:
 Hi,

 as I'm currently on the way to redesign the TrueType/OpenType file
 reading, from time to time I stumble over some odd things.

 But instead of blindly refactoring, I think its better to ask you
 before.

 Fonts have among other things the properties ascent, descent and
 fontBBox which are defined in the PDF spec chapter 5.7 Font Descriptors.

 If I look into PDFFactory rev. 800217 line 1445 - 1483 method
 makeFontDescriptor, I see two constructor calls, one for CID fonts and
 one for the other fonts. For CID fonts the constructor of
 PDFCIDFontDescriptor is called and for the others the constructor of
 PDFFontDescriptor is called. PDFCIDFontDescriptor is a subclass of
 PDFFontDescriptor.

 The odd thing here is, that the call of PDFCIDFontDescriptor doesn't use
 the ascent nor the descent of the font descriptor. Instead it uses some
 quantities out of the fontBBox to feed the PDFFontDescriptor. This can
 be seen inside PDFCIDFontDescriptor rev. 679326.

 So as fontBBox, ascent and descent don't be the same thing, I would
 recommend to change this. But this would properly break some things,
 because we would get other values for ascent and descent in CID fonts.


 Best Regards
 Alex

 -
 e-mail: alexanderk...@gmx.net
 web:    www.alexanderkiel.net

Re: State of OpenType Font Implementation

[Max Berger]

Alex,

please note that the FOP code has been developed by multiple volunteers
over the last ten years. As such, it does not always follow one clear
path of design.

That said, refactoring the FOP code for easier reading / maintainability
is definitely wanted! The proper steps would be:

- ensure that there are junit tests for the existing functionality. If
not, add them.

- ensure all junit tests run on your machine

- refactor away, keeping in mind fop's conventions:
http://xmlgraphics.apache.org/fop/dev/conventions.html
Please note that FOP is currently still on Java 1.4.

- ensure all junit tests still pass

- create a bug report with [patch] in the subject line and attach your
patch.

Max

Alexander Kiel schrieb:
 Hi Jeremias,
 
 ok I think the first step would be to add CFF support into
 org.apache.fop.fonts.truetype.TTFFile or to split TTFFile into
 TrueTypeFile and OpenTypeFile and add CFF support only to OpenTypeFile.
 
 In the last hour I waded through TTFReader, TTFFile, TTFDirTabEntry and
 the OpenType Spec [1]. What about refactoring this code mess as a whole?
 I mean seriously, does all of the FOP code looks like this one?
 
 
 Best Regards
 Alex 
 
 
 [1]: http://www.microsoft.com/typography/otspec/otff.htm
 
 -  
 e-mail: alexanderk...@gmx.net
 web:www.alexanderkiel.net
 
 
 On Tue, 2009-09-15 at 09:48 +0200, Jeremias Maerki wrote:
 Hi Alex,

 second good news today. I guess we need to define what should be covered
 by Open Type. One important aspect is certainly CFF support (which
 I've just mentioned to Jonathan a few minutes ago). Another aspect is
 what Bertrand Delacrétaz started to look into: ligatures, character
 combination and such. CFF should be relatively easy to implement.
 Ligature support is going to be much harder as this will have effects
 into the layout engine.

 OpenType fonts that have TrueType glyphs and don't require the advanced
 typographical stuff are already supported today, but many OTF fonts have
 CFF glyph data. So that would be the first priority IMO.

 On 15.09.2009 09:23:39 Alexander Kiel wrote:
 Hi,

 I'm new to the fop-dev list but use FOP for some years already.

 Recently I tried to use OpenType fonts. As documented FOP doesn't
 support OpenType fonts yet.

 The last and only discussion I could found on fop-dev is from 2006 [1].
 Looking into the trunk, there is not really anything done with respect
 to OpenType. So what is the state of OpenType support in 2009?

 Sure I could possibly help implementing it.

 Best Regards
 Alex


 [1]:
 http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg04892.html

 -  
 e-mail: alexanderk...@gmx.net
 web:www.alexanderkiel.net




 Jeremias Maerki




-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Moving to Java 1.5, retroweaving for 1.4

[Max Berger]

Dear Fop Devs,

Peter B. West schrieb:
 Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit
 machines. Apple's commitment to Java has slackened off considerably.
 Peter

Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes Java 6
on 32-bit intel architectures [and was not yet released at the time of
the original post].

Max


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Moving to Java 1.5, retroweaving for 1.4

[Max Berger]

Dear Fop-Devs,

since I am one of the people cited for moving forward to 1.5, I just
want to throw my 2 cts in the mix:

I would prefer a new release first, and then moving to 1.5.

Rationale:

1) Retroweaving works, but there will be some bugs which will have to
be ironed out and tested. The last release (0.95) has been done quite
a long time back, and the next release will take even longer when a
new feature (1.5) is added.

2) Since the 0.9x releases are test-releases towards 1.0, they
should have the same features / requirements.

3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas
the 1.0 branch could stay on 1.4

As an example from another apache project: Maven moved from 2.1.0 to
2.2.0 rather than 2.1.x because they now require java 1.5 and did not
want to make this a minor upgrade

Max

2009/8/20 Simon Pepping spepp...@leverkruid.eu:
 On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote:
 Jeremias Maerki wrote:
 There we go again. ;-) I can understand the wishes and cravings of the
 developers (feeling them myself), but as I've said before: such a
 decision should be made with the user community in the back, i.e. there
 should be another user survey to gather current data. Just because Sun
 EOLs a Java version doesn't mean that everyone can suddenly just do the
 switch. So why don't those who want this change so badly do that little
 survey so we have the data on an informed decision?

 Hi All,

 I'm not so against this idea 1 year further on but I still have
 concerns that we would force x% of users to stay on 0.95 if we do
 this. I agree with Jeremias' proposal to run a survey on fop-users
 for a couple of weeks to get some hard facts to help make an
 informed decision.

 Also, I think it is something that could wait until after the long
 promised 1.0 release. With the changing IPD feature being one of the
 last major features of 0.20.x missing from 0.9x that is now
 available we should consider doing the v1.0 release and then if the
 survey shows the number of 1.4 and earlier users to be very low then
 we should do the switch.

 I agree that we should proceed with a 1.0 release.

 I can also agree with releasing it compliant with Java 1.4.

 I note, however, that the methods I removed were several methods in
 class Character which are very useful in character handling, such as
 the method Character.toChars(int), which is the main method to convert
 an integer to an array of chars. That means that for Unicode values
 above 0x there is no good method to turn the value into a char[]
 or String. Also Characters.toLowerCase, toUpperCase, toTitleCase,
 getType, $UnicodeBlock. For a text handling application in 2009 that
 is a bit painful.

 Simon

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

Re: svn commit: r772672 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/apps/FOURIResolver.java

[Max Berger]

Hi *,

Andreas Delmelle schrieb:
 snip /
 Whilst you are both technically correct, I made the change because
 backslashes in file URLs used to work until revision 752153 when
 Jeremias inadvertantly removed support for this. Whilst this may be
 against the URL spec this is a feature that improves usability of the
 product. A lot of users out there aren't aware of the details of RFC
 2396 and are used to being able to use backslashes in file URLs
 (especially on Windows systems). So if we remove support for this we may
 get a few more questions on fop-user.

For a windows user \ is a valid path separator, and should be kept
working as path separator.

If this function is the right place may be debatable.

 Performing the substitution as part of basic URI resolution, for any
 protocol or on another platform introduces a genuine bug, while not
 resolving paths as URIs on one platform seems just an inconvenience.

Here is another idea: Just substitute File.separator with /

Pro: Would satisfy windows users
Pro: The misbehavior only exists on windows.
Con: URI Resolver would work differently on different plattforms.

 Cheers
 Andreas

Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: FOP page break

[Max Berger]

Dear Umesh,

just saw that your email has not been answered yet: Your request was
based on an old version of fop, which is no longer supported. Please
retry with fop 0.95, and if the issue persist, open a bug report as
shown at: http://xmlgraphics.apache.org/fop/gethelp.html#enter-issue

Max

2009/4/21  umesh.val...@olympus.com:

 Hi,
 I am the user of FOP project and need to seek your help on one of the issues
 I am struggling with.
 Attached file (.fo) contains the page that we render to the printer and
 causes the page break after following FO block.
 We are using FOP-0.20.4a FOP version. Also using the XSLT transformation
 file (attached) to transform HTML to .FO document before it is rendered to
 the printer.

 The FO document causing issue (attached) = page-break-FOP.fo
 corresponding xslt (attached )= xhtml2fo.xsl

 Your help is highly appreciated!!!


 fo:block role=p space-after=0.2em
 fo:inline font-weight=bold role=bFindings:/fo:inline  A single polyp
 (measuring between 5 and 10 mm in size) was found in the hepatic
 flexure.fo:external-graphic content-width=scale-to-fit role=img
 src=url('endoworks/servlet/ImageIconServlet?num=1amp;jsessionid=1F6B27727915B4894F1ED63C8613E44Aamp;traceid=244')/
 The polyp was removed with a snare and placed in jar 1. A single polyp,
 measuring between 5 and 10 mm in size, was found in the splenic
 flexure.fo:external-graphic content-width=scale-to-fit role=img
 src=url('endoworks/servlet/ImageIconServlet?num=3amp;jsessionid=1F6B27727915B4894F1ED63C8613E44Aamp;traceid=245')/
 The polyp was removed by snare cautery polypectomy. A single polyp,
 measuring less than 5 mm in size, was found in the sigmoid. The polyp was
 removed by snare cautery polypectomy and placed in jar 3. There was evidence
 of moderately severe diverticulosis in the sigmoid. Small internal
 hemorrhoids were found in the rectum. There was evidence of a right
 colectomy in the hepatic flexure.fo:external-graphic
 content-width=scale-to-fit role=img
 src=url('endoworks/servlet/ImageIconServlet?num=2amp;jsessionid=1F6B27727915B4894F1ED63C8613E44Aamp;traceid=246')/
 /fo:block





 regards, Umesh
 Medical Information Technologies
 Olympus America Inc.
 Tel: 484-896-5598

Re: Help for svg on IBM AIX

[Max Berger]

Dear Bibhu Das,

you have addressed the wrong mailing list. This list is about
development of fop. For usage problems, please send an email to fop-user.

Bibhu_Das schrieb:
 I have installed the X11 libraries for displaying bar graphs which is
 done by svg fo:instream-foreign-object.
 Can I know the name of specific libraries for displaying svg bar graphs.

For SVG you need the batik libraries, which are part of the fop standard
distribution. So the problem here seems to be something else. Please add:
- a minimal .fo file which shows your problem
- the exact output when you run fop

 Thanks and Regards
 Bibhu Das

Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Merge branch for new Intermediate Format into Trunk

[Max Berger]

Dear fop-devs,

ran junit, tested with some of my documents. For an 80 page document
(ran 3 times): avg. 40 sec (new) vs. 45 sec (old). Will look into
repairing the JEuclid plugin again after the merge.


+1


Max


Jeremias Maerki schrieb:
 As mentioned earlier, I would like to start a vote for merging the
 Intermediate Format branch [1] (revision 744946) into Trunk.
 
 [1] 
 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign
 
 +1 from me.
 
 Jeremias Maerki
 


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Performance benchmark on new Intermediate Format

[Max Berger]

Jeremias,

Jeremias Maerki schrieb:
 I've written a short report on the performance of the new Intermediate
 Format. The numbers show that the goals have been met. It's also
 interesting to look at from a general perspective. I'm sure there could
 be a lot more that I could have written and shown but at some point I
 had to warp it up. I hope I didn't leave out anything crucial.
 
 http://people.apache.org/~jeremias/fop/benchmark-2009-02-13/

Looks really nice. Finally some numbers on FOPs performance, the tests
you did seem to make sense. Thank you for this work! I think this should
be merged as soon as possible.

 My next step is to try to meet Vincent's high coding standards (although
 that's probably a lost cause for me) and then to get the approval for
 the merge into trunk.

I've just committed the following changes:
- Fixed PMD to report only basic issues and important security issues.
run ant pmd to get this report. This is something I'll look into
changing in fop trunk after the merge.
- added the PMD/CPD (Copy'n'paste detection) report, run ant cpd to
generate it. Anything reported here should definitely be refactored.
Again, I'll look into some of these things after your merge.

PMD requires JDK 1.5 (only needed for report, and not for normal build
or use, hope this is ok)

Hotspot does pretty well on inlining static functions, duplicate code
could therefore go into static functions in utility classes if they
would not make sense in the class hierachy.


 Have a good weekend,
 Jeremias Maerki

hth

Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: examples/mathml

[Max Berger]

done in rev. 736295.

Max

Max Berger schrieb:
 Dear Fop-Devs,
=20
 Vincent Hennebert schrieb:
 Hi,

 Jeremias Maerki wrote:
 The MathML plugin in FOP works with JEuclid 1.0. But since a lot of w=
ork
 has gone into JEuclid over the past months and it now has its own
 plug-in it may make sense to remove that part completely. We still ha=
ve
 the Plan Demo plug-in as the primary extension example (which I'd lik=
e
 to keep operational) and both Barcode4J and JEuclid are open source a=
nd
 can therefore serve as additional examples for creating FOP plug-ins.=

 +1 for removing the MathML examples from the code base.
=20
 +1 here too, I am even volunteering to do it (I'd add a link to JEuclid=

 instead)
=20
 Max

--=20
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Character-by-character font selection strategy

[Max Berger]

Dongsheng,

looks like you'll have to wait for proper character selection to be
implemented - this should solve your problems. For now you could try to
add a space between your characters and the rest of the word, or use a
full unicode font such as DejaVu.

Max

Dongsheng Song schrieb:
 Did you mean this example[1] ? It great increase the fo file size,
 and I use DocBook, don't know how to use this feather in xsl,
 can you give me some advice ?
 
 [1] http://www.zvon.org/HowTo/Output/FOP0.18.1_examples_character.php
 
 Dongsheng Song
 
 2009/1/16 Max Berger m...@berger.name:
 there is: please use fo:character, which should work just as expected.



-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: examples/mathml

[Max Berger]

Dear Fop-Devs,

Vincent Hennebert schrieb:
 Hi,
 
 Jeremias Maerki wrote:
 The MathML plugin in FOP works with JEuclid 1.0. But since a lot of work
 has gone into JEuclid over the past months and it now has its own
 plug-in it may make sense to remove that part completely. We still have
 the Plan Demo plug-in as the primary extension example (which I'd like
 to keep operational) and both Barcode4J and JEuclid are open source and
 can therefore serve as additional examples for creating FOP plug-ins.
 
 +1 for removing the MathML examples from the code base.

+1 here too, I am even volunteering to do it (I'd add a link to JEuclid
instead)

Max

-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Character-by-character font selection strategy

[Max Berger]

Dear Dongsheng Song,

the patch you refer to is outdated and the issue of character handling
has changed since your quoted messages. I have just now updated the Wiki
to reflect the changes. Please email back to the list if anything is
unclear.

Max

Dongsheng Song schrieb:
 II have been googled the discuss[1,2], and Max Berger's patch[3], and
 the wiki[4].
 The patch or wiki is too old, not apply to the trunk.
 
 What's the current status, can someone update it ? I
 
 [1] http://marc.info/?t=11829738402r=1w=2
 [2] http://marc.info/?t=11780260132r=1w=2
 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422
 [4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy
 
 Dongsheng Song


-- 
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700



signature.asc
Description: OpenPGP digital signature

Re: Character-by-character font selection strategy

[Max Berger]

Dongshen,

there is: please use fo:character, which should work just as expected.

hth

Max

Am 15.01.2009 15:02, schrieb Dongsheng Song:

The wiki[2] same as web[1] for 'Font Selection Strategies'. But 'Word-by-Word'
can't meet my case. For string '#xB2E2;#xCAD4;teststring', if I specify
font-family=Times, SimSun, FOP paint using Times characters, not SimSun,
so I got missing glyphs.

I's there a way treat a single Chinese char(e.g. '#xB2E2') as a word ?

[1] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy
[2] http://xmlgraphics.apache.org/fop/trunk/fonts.html#selection

2009/1/15 Max Bergerm...@berger.name:

Dear Dongsheng Song,

the patch you refer to is outdated and the issue of character handling
has changed since your quoted messages. I have just now updated the Wiki
to reflect the changes. Please email back to the list if anything is
unclear.

Max

Dongsheng Song schrieb:

II have been googled the discuss[1,2], and Max Berger's patch[3], and
the wiki[4].
The patch or wiki is too old, not apply to the trunk.

What's the current status, can someone update it ? I

[1] http://marc.info/?t=11829738402r=1w=2
[2] http://marc.info/?t=11780260132r=1w=2
[3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422
[4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy

Dongsheng Song


--
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

[Max Berger]

Adrian,

since I have not actually followed the code:

+0.5

The recent amount of discussion shows that your branch should be
integrated into trunk as soon as possible, since it touches other areas
as well, and these issues need to be resolved before 1.0beta.

Max

Vincent Hennebert schrieb:
 Hi Adrian,
 
 I don’t know much about AFP, but from the little I know I fully imagine
 that this must have been all but an easy task.
 I haven’t followed your work closely, but you seem to have put a lot of
 effort to it. Congratulations, and here’s my +1.
 
 Vincent
 
 
 Adrian Cumiskey wrote:
 Hi all,

 I would like to call for a merge of the AFP branch [1] back into trunk.

 This branch [1] contains a major rewrite of pretty much all the
 original AFP code.  The majority of
 the AFP code is now homed in its own package separate from the
 renderer code in org.apache.fop.afp.
 The AFPRenderer itself is now only sone 800 or so lines long down from
 the previous 1800+ lines and
 now more properly extends the AbstractPathOrientedRenderer.  There is
 also now much more shared code
 now betweeen the PDF and AFP renderers.

 Major new functionality in the branch includes :-

 * An AFPGraphics2D implementation which provides the ability to use
 Batik to drive the production of
  AFP Graphics (GOCA) output from SVG.
 * Resource group leveling, external streaming and de-duplication of
 images and graphics using
 IncludeObject and ResourceGroup.
 * Native image embedding support (e.g. JPEG, GIF, TIFF) using
 ObjectContainer and a MOD:CA Registry
 implementation.
 * More robust AFP font parsing, although this is still in need of some
 rework in the future.

 I realize that testing these new AFP features in FOP may not be easy
 for some of you.  You can
 however use the Infoprint Solutions (IBM) AFP Workbench Viewer for
 Windows
 (http://www.ibm.com/support/docview.wss?uid=psd1P4000360) to view the
 output.

 [1]
 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources


 +1 from me.

 Adrian.
 




signature.asc
Description: OpenPGP digital signature

Re: FIleChannel accessible BufferedOutputStream

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adrian,

when doing this you need to be very careful that either the
BufferedOutputStream OR the FileChannel methods are used. If you start
mixing both you will get very strange effects.  So for safety I would
prefer to pass either a stream or a channel to a renderer, but not both.

Also, you need to make sure that the AFP renderer work if just a Stream
is available - this could be needed in cases where the output is stdout
(although I don't know if this would be a common use case).

Maybe a wrapper class similar to the idea of org.xml.sax.InputSource
would do the trick?

Max

Adrian Cumiskey schrieb:
 When FOP is started in Main.startFOP() a java.io.BufferedOutputStream is
 instantiated and wrapped around an instantiated
 java.io.FileOutputStream.  By wrapping the initial
 java.io.FileOutputStream with a java.io.BufferedOutputStream, FOP is not
 able to potentially make use of the nio FileChannel stuff which could
 provide more efficient final output writing (using modern operating
 system caching) [1].
 
 This would especially be the case for AFP writing as output is initially
 written in two parts for memory saving reasons, one outputstream for
 document resources and one for the actual document.  On completion of
 rendering the document is appended to the end of the document resources
 outputstream.
 
 So I am proposing the introduction and instantiation of a
 FileChannelAccessibleBufferedOutputStream which extends
 java.io.BufferedOutputStream in Main.startFOP().  It will expose the
 getChannel() method of java.io.FileOutputStream.  I have included the
 small code changes I am proposing below. Does this sound reasonable and
 would this cause any problems for anyone?
 
 Adrian.
 
 [1] http://java.sun.com/j2se/1.4.2/docs/guide/nio
 
 Index: java/org/apache/fop/cli/Main.java
 ===
 --- java/org/apache/fop/cli/Main.java   (revision 708875)
 +++ java/org/apache/fop/cli/Main.java   (working copy)
 @@ -21,6 +21,7 @@
 
  import java.io.File;
  import java.io.FileFilter;
 +import java.io.FileOutputStream;
  import java.io.OutputStream;
  import java.lang.reflect.Method;
  import java.net.MalformedURLException;
 @@ -28,9 +29,9 @@
  import java.util.List;
 
  import org.apache.commons.io.IOUtils;
 -
  import org.apache.fop.apps.FOUserAgent;
  import org.apache.fop.apps.MimeConstants;
 +import org.apache.fop.util.FileChannelAccessibleBufferedOutputStream;
 
  /**
   * Main command-line class for Apache FOP.
 @@ -164,8 +165,9 @@
 
  try {
  if (options.getOutputFile() != null) {
 -out = new java.io.BufferedOutputStream(
 -new
 java.io.FileOutputStream(options.getOutputFile()));
 +FileOutputStream fileOutputStream
 += new
 java.io.FileOutputStream(options.getOutputFile());
 +out = new
 FileChannelAccessibleBufferedOutputStream(fileOutputStream);
  foUserAgent.setOutputFile(options.getOutputFile());
  } else if (options.isOutputToStdOut()) {
  out = new java.io.BufferedOutputStream(System.out);
 
 --- snip ---
 
 /*
  * Licensed to the Apache Software Foundation (ASF) under one or more
  * contributor license agreements.  See the NOTICE file distributed with
  * this work for additional information regarding copyright ownership.
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the License); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
  *
  *  http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an AS IS BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 
 /* $Id: $ */
 package org.apache.fop.util;
 
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.nio.channels.FileChannel;
 
 /**
  * A BufferedOutputStream implementation that provides access to the
 underlying FileChannel.
  * This allows for the potential use of nio FileChannel.transferTo() and
 FileChannel.transferFrom().
  */
 public class FileChannelAccessibleBufferedOutputStream extends
 java.io.BufferedOutputStream {
 
 private final FileOutputStream fos;
 
 /**
  * Main constructor
  *
  * @param fos file output stream
  */
 public FileChannelAccessibleBufferedOutputStream(FileOutputStream
 fos) {
 super(fos);
 this.fos = fos;
 }
 
 /**
  * Returns the file channel
  *
  * @return the file channel
  * @throws IOException thrown if an I/O exception of some sort has
 occurred
  */
 public FileChannel 

Re: Problem upgrading from 0.94 to 0.95

[Max Berger]

Paul,

due to changes in the ImageLoader API you have to use matching version
of JEuclid for FOP to work.

I tried to reproduce your error and I was unable to reproduce it using
FOP trunk and JEuclid 3.1.3.

Also, in the .fo given:
http://www.nabble.com/file/p20339979/doc.xml.fo

There is no MathML used.

If this is the file you're having trouble with:
- delete (temporary) the jeuclid libs and see if that helps. If so, I
need to fix this in JEuclid [ I'll then ask for more information ].
- if that did not change anything it's a bug in fop. In this case,
please make the PNG files available, maybe there error lies therein?


Max



Nobble schrieb:
 I have now tried with the combination: apache fop 0.95 and jEuclid 3.0.3. I
 get this error:
 
 Making portrait pages on A4 paper (210mmx297mm)
 Exception in thread main java.lang.NoClassDefFoundError:
 org/apache/fop/image/analyser/XMLReader$Converter
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:169)
 at
 org.apache.fop.fo.ElementMappingRegistry.addElementMapping(ElementMappingRegistry.java:94)
 at
 org.apache.fop.fo.ElementMappingRegistry.setupDefaultMappings(ElementMappingRegistry.java:77)
 at
 org.apache.fop.fo.ElementMappingRegistry.init(ElementMappingRegistry.java:64)
 at org.apache.fop.apps.FopFactory.init(FopFactory.java:151)
 at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:166)
 at
 org.apache.fop.cli.CommandLineOptions.init(CommandLineOptions.java:102)
 at org.apache.fop.cli.Main.startFOP(Main.java:153)
 at org.apache.fop.cli.Main.main(Main.java:197)
 
 Paul
 
 
 Adrian Cumiskey wrote:
 Also it may be helpful if you are able to tell us which version of JEuclid
 you are using.

 Adrian.





signature.asc
Description: OpenPGP digital signature

Re: FOP 0.95 and Maven2

[Max Berger]

Dear Sean,

I was misinformed - the javadoc and source jars are actually built, so
at this time the only problem we have is that they are not voted releases.

I'd therefore suggest that we try to include the maven bundle in the
release and voting process for future releases.

Max


Max Berger schrieb:
 Dear Sean,
 
 there are several issues here:
 
 - we are only allowed to deploy voted releases in the maven
 repository. As there are currently no fop source and javadoc jars, this
 would require a re-vote, which would probably be too much trouble.
 Therefore, if we do this it would be from 0.96 onward and not for 0.95
 
 - Currently these jars are not built - we use ant as the build system
 and not maven, and the maven artifacts are a byproduct of the main
 release build. We would need proper ant-tasks to build these artifacts.
 
 - The maven artifacts are a low-priority for most developers, but If you
 provide patches I hope we can discuss this as a feature for future releases.
 
 Max
 
 
 Am 30.09.2008 um 16:34 schrieb Griffin,Sean:
 
 Worked like a charm.  Thanks!  Any thoughts of publishing the source
 and javadoc JARs with the binary?  I notice this isn’t done across the
 board for some other apache jars I looked at, like xmlgraphics-commons
 and batik, but it can make debugging issues considerably easier.
  
 *From:* Max Berger [mailto:[EMAIL PROTECTED] *On Behalf Of *Max Berger
 *Sent:* Saturday, September 27, 2008 4:39 PM
 *To:* fop-dev@xmlgraphics.apache.org
 mailto:fop-dev@xmlgraphics.apache.org
 *Subject:* Re: FOP 0.95 and Maven2
  
 Dear Sean,
  
 should be uploaded now, and sync with the main repository within 24
 hours. Please let me know if you encounter any problems.
  
 Max
  
 Am 26.09.2008 um 20:20 schrieb Griffin,Sean:


 Developers,

 Are there any plans to push the new FOP 0.95 release to the central
 Maven repo?

 *Sean Griffin* | Clinical Reporting Architect | Cerner Corporation |
 816.201.1599 | [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] | www.cerner.com http://www.cerner.com

  
 
 CONFIDENTIALITY NOTICE This message and any included attachments are
 from Cerner Corporation and are intended only for the addressee. The
 information contained in this message is confidential and may
 constitute inside or non-public information under international,
 federal, or state securities laws. Unauthorized forwarding, printing,
 copying, distribution, or use of such information is strictly
 prohibited and may be unlawful. If you are not the addressee, please
 promptly delete this message and notify the sender of the delivery
 error by e-mail or you may call Cerner's corporate offices in Kansas
 City, Missouri, U.S.A at (+1) (816)221-1024.
  
 




signature.asc
Description: OpenPGP digital signature

Re: FOP 0.95 and Maven2

[Max Berger]

Dear Sean,

there are several issues here:

- we are only allowed to deploy voted releases in the maven  
repository. As there are currently no fop source and javadoc jars,  
this would require a re-vote, which would probably be too much  
trouble. Therefore, if we do this it would be from 0.96 onward and not  
for 0.95


- Currently these jars are not built - we use ant as the build system  
and not maven, and the maven artifacts are a byproduct of the main  
release build. We would need proper ant-tasks to build these artifacts.


- The maven artifacts are a low-priority for most developers, but If  
you provide patches I hope we can discuss this as a feature for future  
releases.


Max


Am 30.09.2008 um 16:34 schrieb Griffin,Sean:

Worked like a charm.  Thanks!  Any thoughts of publishing the source  
and javadoc JARs with the binary?  I notice this isn’t done across  
the board for some other apache jars I looked at, like xmlgraphics- 
commons and batik, but it can make debugging issues considerably  
easier.


From: Max Berger [mailto:[EMAIL PROTECTED] On Behalf Of Max Berger
Sent: Saturday, September 27, 2008 4:39 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: FOP 0.95 and Maven2

Dear Sean,

should be uploaded now, and sync with the main repository within 24  
hours. Please let me know if you encounter any problems.


Max

Am 26.09.2008 um 20:20 schrieb Griffin,Sean:


Developers,

Are there any plans to push the new FOP 0.95 release to the central  
Maven repo?


Sean Griffin | Clinical Reporting Architect | Cerner Corporation |  
816.201.1599 | [EMAIL PROTECTED] | www.cerner.com



CONFIDENTIALITY NOTICE This message and any included attachments are  
from Cerner Corporation and are intended only for the addressee. The  
information contained in this message is confidential and may  
constitute inside or non-public information under international,  
federal, or state securities laws. Unauthorized forwarding,  
printing, copying, distribution, or use of such information is  
strictly prohibited and may be unlawful. If you are not the  
addressee, please promptly delete this message and notify the sender  
of the delivery error by e-mail or you may call Cerner's corporate  
offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.






PGP.sig
Description: This is a digitally signed message part

URIResolutionTestCase is disabled

[Max Berger]

Dear Fop-devs,

is there a specific reason why URIResolutionTestCase is disabled?

May I re-enable it (as in the attached patch)?

Background: Before I do further URI-Resolver patching / moving I would
like to test the current behavior as not to break anything.

Max

Index: test/java/org/apache/fop/UtilityCodeTestSuite.java
===
--- test/java/org/apache/fop/UtilityCodeTestSuite.java	(revision 689009)
+++ test/java/org/apache/fop/UtilityCodeTestSuite.java	(working copy)
@@ -50,6 +50,7 @@
 suite.addTest(new TestSuite(ElementListUtilsTestCase.class));
 suite.addTest(new TestSuite(BasicEventTestCase.class));
 suite.addTest(new TestSuite(XMLResourceBundleTestCase.class));
+suite.addTest(new TestSuite(URIResolutionTestCase.class));
 //$JUnit-END$
 return suite;
 }

URIResolvers (Re: (Re)moving without deprecating?)

[Max Berger]

Jeremias,

my fault again. You are absolutely right, I should provide a
deprecated version of the old classes in all cases, and probably
discuss the idea.

I'll do the later today, and here's the second one:

Background is this thread [1] which showed a flaw in the way FOP
resolves URIs.

Current Situation:
* FOP provides support for 1 Custom Resolver
* It also adds the data: URI resolver
* and has a sophisticated resolving method for other URIs which are
openable through URL.open (better than the JDK default)

Problem:
A plugin cannot add a URIResolver to FOP, as there is only 1 custom
resolver, and it is defined by the user.

Main Idea:
Support a generic chain of URIResolvers. All URI resolvers are called
in order, if one of them can resolve the URI it will return a source,
otherwise null.

Implementation Idea:
Need a URIResolver registry, like the ImageLoader registry. It should
automatically load all URIResolvers declared as service, and provide
register() and unregister() functionality.

A Generic URI resolver will then try all registered resolvers first, and
then fall back to the default (which would be the functionality as it is
in FOP now).

Plugins can then register their own URI resolver, which could either add
URIs (there are some examples of a XML: URI in commons, which would be
interesting), or provide mapping for well-known URIs, such as the ones
of DTDs and entities.

[1]
http://www.nabble.com/Getting-Batik-to-read-SVG-DTDs-via-catalog-resolver-td18169780.html

Hope this makes sense

Max

Jeremias Maerki schrieb:
 I'm seeing a new pattern here and I'm not entirely happy about it. I'd
 prefer at least a short deprecation time (one release) before final
 removal. Also a short discussion or at least an advance notice about
 someone's intentions and motivations would be appreciated. But maybe
 that's only me.
 
 On 24.08.2008 15:12:02 maxberger wrote:
 Author: maxberger
 Date: Sun Aug 24 06:12:02 2008
 New Revision: 688508

 URL: http://svn.apache.org/viewvc?rev=688508view=rev
 Log:
 Moved DataURIResolver from FOP to commons; use new URIResolver registry

 Removed:
 xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
 
 xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
 Modified:
 xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
 xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
 xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
 
 
 On 20.08.2008 17:13:56 acumiskey wrote:
 Author: acumiskey
 Date: Wed Aug 20 08:13:56 2008
 New Revision: 687369

 URL: http://svn.apache.org/viewvc?rev=687369view=rev
 Log:
 * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
 * Removed UnitConv and its unit test case (now resides in commons).
 * Updated all fop util package references fpr UnitConv to xmlgraphics 
 commons util package.

 Removed:
 xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
 xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
 Modified:
 xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
 xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
 
 
 
 Jeremias Maerki
 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r687323 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: afp/AFPRenderer.java pcl/PCLRenderer.java

[Max Berger]

Dear FopDevs,

I've added the patched version and submitted a feature request for
retroweaver:

https://sourceforge.net/tracker/index.php?func=detailaid=2063970group_id=104240atid=637383

Since the next release date is still a little bit away I hope this can
be fixed properly by then.

Max

Jeremias Maerki schrieb:
 As long as we don't distribute the unreleased package in one of our own
 releases, it's fine. We need to apply the same policy as we do for other
 libraries. If the source distribution doesn't contain those build
 dependencies, it's ok to keep the unreleased package.
 
 On 20.08.2008 18:31:46 Max Berger wrote:
 Dear Fop-Devs,

 further insight on retroweaver:

 I've downloaded and patched retroweaver not to modify Boolean.valueOf,
 which is now correctly verified against 1.4. I could add the (patched)
 artifact to fops lib/build.  I will try and discuss with the retroweaver
 maintainer about options to include that into the standard retroweaver
 distribution.

 What is the opinion about having patched and unreleased dependencies?
 Even if it is just for build, and purely optional?

 Max

 Max Berger schrieb:
 Adrian,

 Adrian Cumiskey schrieb:
 I don't think it is Max... looks like @since 1.4.
 you're right - looks like the other valueOf methods (for integer, etc.)
 where introduced in 1.5, and this one was indeed introduced in 1.4.

 I've reverted that change.

 Apparently retroweaver still modifies calls to Boolean.valueOf,
 according to the doc to be compatible with 1.3.

 Unfortunately this requires adding the retroweaver-runtime to the
 verification classpath, which then renders the verification process
 useless, as it is supposed to detect failures like Integer.valueOf(),
 which will now again slip through.

 I'll look deeper into retoweaver to see if I can find a suitable solution.

 Max


 
 
 
 
 Jeremias Maerki
 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r687327 - in /xmlgraphics/fop/trunk: build.properties build.xml

[Max Berger]

Dear Fop-Devs,

I hope this commit does not break gump - if so I'll revert it.

What this does: If you set properties to point to a java 1.4
installation, it will try to verify if fop uses only the classes
available there and output a warning.

The retroweaving process is currently done but unsused (unfortunately it
cannot be turned of, so it just weaves to a temp directory) - so no 1.5
features are available. Experiments in separate branches are welcome
(result of the discussion we had previously on that matter).

As a note of success: I found two cases of valueOf in the code, (see
my commit 687323) which slipped in there accidentally.

Should this prove successfully I would like to
- make the warning bigger
- add a note that committers *should* have jdk 1.4 installed

Max


[EMAIL PROTECTED] schrieb:
 Author: maxberger
 Date: Wed Aug 20 06:32:19 2008
 New Revision: 687327
 
 URL: http://svn.apache.org/viewvc?rev=687327view=rev
 Log:
 Use retroweaver for 1.4 verification
 
 Modified:
 xmlgraphics/fop/trunk/build.properties
 xmlgraphics/fop/trunk/build.xml
 
 Modified: xmlgraphics/fop/trunk/build.properties
 URL: 
 http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.properties?rev=687327r1=687326r2=687327view=diff
 ==
 --- xmlgraphics/fop/trunk/build.properties (original)
 +++ xmlgraphics/fop/trunk/build.properties Wed Aug 20 06:32:19 2008
 @@ -17,6 +17,13 @@
  ## checkstyle binary distribution.
  # checkstyle.home.dir = /home/bart/stuff/checkstyle-4.0-beta6
  
 +## Path to the java 1.4 runtime libary (rt.jar on most systems)
 +## On OS X this is 
 /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Classes/classes.jar
 +#java14.rt.lib=/opt/j2re1.4.2_07/lib/rt.jar
 +## Path to the java 1.4 jce libary (jce.jar on most systems)
 +## On OS X this is 
 /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Classes/jce.jar
 +#java14.jce.lib=/opt/j2re1.4.2_07/lib/jce.jar
 +
  ## ===
  ## 2. Switches for common tasks
  
 @@ -44,4 +51,4 @@
  
  ## Specify an alternate directory to scan for user supplied
  ## hyphenation pattern files.
 -# user.hyph.dir = /home/bart/offo
 \ No newline at end of file
 +# user.hyph.dir = /home/bart/offo
 
 Modified: xmlgraphics/fop/trunk/build.xml
 URL: 
 http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.xml?rev=687327r1=687326r2=687327view=diff
 ==
 --- xmlgraphics/fop/trunk/build.xml (original)
 +++ xmlgraphics/fop/trunk/build.xml Wed Aug 20 06:32:19 2008
 @@ -459,15 +459,31 @@
/manifest
  /jar
/target
 -  target name=retro depends=compile
 -!--
 +  target name=retro-unavail unless=java14.rt.lib
 +echo message=Please set the path to a JDK 1.4 installation in your 
 build-local.properties /
 +echo message=to allow for verification! /
 +  /target
 +  target name=retro-avail depends=compile if=java14.rt.lib
  taskdef name=retroweaver 
 classname=net.sourceforge.retroweaver.ant.RetroWeaverTask
classpath
 -path refid=libs-build-classpath/
  path refid=libs-build-tools-classpath/
/classpath
  /taskdef
 -RetroWeaver will be added here --
 +path id=verify-classpath
 +  pathelement location=${java14.rt.lib}/
 +  pathelement location=${java14.jce.lib}/
 +  pathelement location=${ant.home}/lib/ant.jar/
 +  path refid=libs-build-classpath/
 +/path
 +!-- If we decide to use retroweaver for the actual weaving, the mkdir 
 and
 + destdir= will have to be removed. Also, the weaving task would 
 additionally
 +  need to be defined even if no jdk 14 is available. --
 +mkdir dir=${build.dir}/temp/
 +retroweaver srcdir=${build.classes.dir} destdir=${build.dir}/temp
 +   classpathref=verify-classpath lazy=false
 +   verify=true target=1.4 /
 +  /target
 +  target name=retro depends=retro-avail,retro-unavail,compile
/target
  !-- === --
  !-- main FOP JARs   --
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r687323 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: afp/AFPRenderer.java pcl/PCLRenderer.java

[Max Berger]

Adrian,

Adrian Cumiskey schrieb:
 I don't think it is Max... looks like @since 1.4.

you're right - looks like the other valueOf methods (for integer, etc.)
where introduced in 1.5, and this one was indeed introduced in 1.4.

I've reverted that change.

Apparently retroweaver still modifies calls to Boolean.valueOf,
according to the doc to be compatible with 1.3.

Unfortunately this requires adding the retroweaver-runtime to the
verification classpath, which then renders the verification process
useless, as it is supposed to detect failures like Integer.valueOf(),
which will now again slip through.

I'll look deeper into retoweaver to see if I can find a suitable solution.

Max



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r687323 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: afp/AFPRenderer.java pcl/PCLRenderer.java

[Max Berger]

Dear Fop-Devs,

further insight on retroweaver:

I've downloaded and patched retroweaver not to modify Boolean.valueOf,
which is now correctly verified against 1.4. I could add the (patched)
artifact to fops lib/build.  I will try and discuss with the retroweaver
maintainer about options to include that into the standard retroweaver
distribution.

What is the opinion about having patched and unreleased dependencies?
Even if it is just for build, and purely optional?

Max

Max Berger schrieb:
 Adrian,
 
 Adrian Cumiskey schrieb:
 I don't think it is Max... looks like @since 1.4.
 
 you're right - looks like the other valueOf methods (for integer, etc.)
 where introduced in 1.5, and this one was indeed introduced in 1.4.
 
 I've reverted that change.
 
 Apparently retroweaver still modifies calls to Boolean.valueOf,
 according to the doc to be compatible with 1.3.
 
 Unfortunately this requires adding the retroweaver-runtime to the
 verification classpath, which then renders the verification process
 useless, as it is supposed to detect failures like Integer.valueOf(),
 which will now again slip through.
 
 I'll look deeper into retoweaver to see if I can find a suitable solution.
 
 Max
 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

[Max Berger]

Adrian,

for the same reason I must disagree with the this change: If the fonts
are not available (symbol, zapf dingbats), fop will just fall back to
the default font, where the character is also not available. What you
loose in this case is a little bit of performance. What you gain is the
chance that fop is finally able to produce special characters (which has
been a missing feature for a long time). So rather than shorting this
list, you could enlengthen it with the symbol fonts available in afp.

Max

Andreas Delmelle schrieb:
 On Jul 17, 2008, at 19:39, [EMAIL PROTECTED] wrote:
 
 Hi Adrian,
 
 Author: acumiskey
 Date: Thu Jul 17 10:39:14 2008
 New Revision: 677648

 URL: http://svn.apache.org/viewvc?rev=677648view=rev
 Log:
 ZapfDingbats and Symbol is not always available on the AFPRenderer so
 we can't have these as default font family properties unfortunately.
 
 I understand... I still think it's a nice showcase for
 character-by-character font-selection added by Max, so I'm wondering, if
 the AFPRenderer is the only exception, we should be looking at a way to
 fall back with a warning, rather than disabling the feature for all
 other output formats as well (?)
 
 Just my 2 cents.
 
 Andreas




signature.asc
Description: OpenPGP digital signature

Re: Building FOP Trunk with Any - BUILD FAILED

[Max Berger]

Bones,

just a quick check: Is there a space in the path to your checkout  
(e.g. C:\Documents and Settings) If so, please try moving the checkout  
to a dir without spaces. (e.g. C:\temp) and see if that helps.


Max


Am 13.07.2008 um 18:24 schrieb Peter B. West:


bonekrusher wrote:

Ok I ran the build under three versions of ant:
Apache Ant version 1.6.5 compiled on June 2 2005
Apache Ant version 1.7.0 compiled on December 13 2006
Apache Ant version 1.7.1 compiled on June 27 2008
All failed. To rule out ant, I downloaded FOP 0.94 src and ran a  
successfully build.
This would leave me to believe that the problem lies in the trunk  
version.

Bones.


You've found a real head-scratcher. I've just done an update on fop,  
and run a clean, followed by package. I don't generally run the  
tests. The build was OK.  H


Can you look at the lib differences between 0.94 and trunk?

--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/




PGP.sig
Description: This is a digitally signed message part

Re: Embedding fonts from JAR: Problem in FOURIResolver.resolve()

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas,

this may not help, but here's a different approach:

Fop (Trunk) supports fonts in jar-files directly, without the need of
font-metrik files. It also adds general support for fonts described with
an URI rather than a file path, which probably solved the problems you
described.

You will need to add auto-detect/ to your fop config file, and prepare
special font jars, as described in:

http://xmlgraphics.apache.org/fop/trunk/fonts.html

This feature is still little tested, so I would be happy to receive any
feedback, especially in the case of a web application, where classloader
issues surface frequently.

Max

Thomas S. schrieb:
 I already posted this message in the fop-user list, but I think it's better
 placed here, cause now
 I think it's not a usage problem.
 
 I use Apache FOP 0.94 to include Truetype-fonts into PDFs, which works
 perfectly, if the needed
 configuration and  font description files are placed in a directory within
 file system, but for usage
 within a web application I pack these files into a JAR file, and this causes
 problems, which I
 suppose to be in method 
 public Source org.apache.fop.apps.FOURIResolver.resolve(String href, String
 base).
 Reading the configuration and including images from the JAR still works, but
 loading the font metric
 unfortunately not.
 
 I also tried 0.95beta with same result, and the implementation of the
 relevant code in trunk seems
 to be unchanged between rev. 567305 (tag for 0.94) and trunk, so this
 applies also for trunk
 version. All mentioned line numbers refer to 0.94 / rev. 567305. Now for the
 details...
 
 The configuration and image-inclusion works with relative URLs, an example
 is:
 href:   image/header.png
 base: jar:file:/path_to_jar/file.jar!/path_within_jar/
 
 This works without a problem!
 
 But when a font within the XSL-FO processing has to be loaded, the method
 FOURIResolver.resolve(String href, String base) is indirectly called from
 LazyFont.load() line: 79, now href is an absolute URL to the font metrics
 file.
 
 So the two argument in FOURIResolver.resolve(String href, String base) are:
 href:  
 jar:file:/path_to_jar/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml
 base: jar:file:/path_to_jar/file.jar!/path_within_jar/
 
 The problem is, that lines 194-196 remove jar: from href, and we run into
 the problem,
 that in line 208 the constructor new URL(URL basURL, String href) is called
 with a href still containing a protocol (file:), which is different from the
 protocol of the
 baseURL (jar:), so absoluteURL = new URL(baseURL, href) sets
 absoluteURL to
 file:/path_to_file/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml.
 This URL doesn't work, cause it's missing the proper protocol specification
 (jar:).
 
 I have to admit, that I don't understand, what lines 197-203 should do (Ok,
 we prepend a slash to
 the url, if there is a colon and a slash in the url, and the colon is places
 before the slash, but why?),
 so I cannot give a proper solution for that problem.
 
 But if it's not needed to remove the scheme from the url, if scheme isn't
 file: (cause only for this
 scheme, the slash is prepended), this diff whould help:
 
 195c236
  if (href.startsWith(scheme)) {
 ---
 if (href.startsWith(scheme)  file:.equals(scheme))
 {
 197d237
  if (file:.equals(scheme)) {
 206d245
  }
 
 What do you think?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh3Kl4ACgkQ+Gr+4pk71Jwo0gCggJNl/G3+3N9YpKFEVIbupkd6
tt0An19wI65V4wa7Ajv0axn6xonQYMpN
=cyfL
-END PGP SIGNATURE-

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vincent,

it may (or may not) make sense to move to commons-cli:

http://commons.apache.org/cli/introduction.html

which addresses this (and other problems) very well, but this would mean
a lot more work.

Max

Jeremias Maerki schrieb:
 Hi Vincent
 
 Certainly not, but you'll probably have to do a few more changes to the
 command-line parser to be able to use the -. You'll see. ;-)
 
 On 11.07.2008 12:01:24 Vincent Hennebert wrote:
 Hi Jeremias,

 Author: jeremias
 Date: Thu Jul 10 12:47:12 2008
 New Revision: 675698

 URL: http://svn.apache.org/viewvc?rev=675698view=rev
 Log:
 Added support for piping:
 - input from stdin (-imagein not supported)
 - output to stdout

 Syntax: fop -xml # -xsl mystylesheet.xsl -pdf #
 (reads the XML from stdin and sends the generated PDF to stdout)
 The de facto standard in the Unix world is to use ‘-’ to specify stdin
 or stdout:
 fop -xml - -xsl mystylesheet.xsl -pdf -

 No objection if I change the code accordingly?

 Thanks,
 Vincent
 
 
 
 
 Jeremias Maerki
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh3RCUACgkQ+Gr+4pk71JyASACfc9j+U87JiPH36L8ApBWvn9p2
myUAnR3Ac7DXQqXPIy6xrrwEKnkkVQAh
=eiDz
-END PGP SIGNATURE-

Re: svn commit: r670341 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FONode.java FOText.java FOTreeBuilder.java FObjMixed.java

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremias,

Jeremias Maerki schrieb:
 Am I the only one concerned about backwards-compatibility here?

No. I am also concerned about backwards-compatibility, but in a
different way:

This change changed the semantics without changing the API, therefore
code still compiled, but crashed (such as the bug I encountered). This
is a type of api change I am not happy with.

What would be ok with me is if the interface had changed (in this case,
the signature of the functions). My code would no longer compile, and
I'd have to prepare a new plugin for the new version (which i currently
have to do anyways).

My favorite solution would be: Provide the new semantics with a new
signature (or method name), and keep the old one as deprecated for at
least 1 release (Then all plugin developers have enough time to adjust),
then remove it.

http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/deprecation/deprecation.html


Max
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIdHqv+Gr+4pk71JwRAoQRAJ9stE0yyjmyBv4eebTru4CDiwSfqgCcCJWI
VTbbnu86aZTMT1/sro8/c2c=
=u05W
-END PGP SIGNATURE-

Re: svn commit: r670422 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ layoutmgr/ layoutmgr/inline/ render/rtf/

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas,

Alhtough the testcases pass, this broke MathML. I get the (attached)
error message on this fo file (which worked fine before updating).
Please note that I get the same error message no matter if the JEuclid
extension is installed or not.

Max

P.S. maybe we should add this as a test file for fop? Of course, there
is no expected output without the extension, but it should not throw an
exception, just a warning.

- --- choose.fo
root xmlns=http://www.w3.org/1999/XSL/Format;
  layout-master-set
simple-page-master master-name=master
  region-body/
/simple-page-master
  /layout-master-set
  page-sequence master-reference=master
flow flow-name=xsl-region-body
  block
instream-foreign-object
  math xmlns=http://www.w3.org/1998/Math/MathML;
mfrac linethickness=0
  mia/mi
  mib/mi
/mfrac
  /math
/instream-foreign-object
  /block
/flow
  /page-sequence
/root
- --- stacktrace

 fop -fo choose.fo -pdf choose.pdf
23.06.2008 15:42:13 org.apache.fop.cli.Main startFOP
SCHWERWIEGEND: Exception
java.lang.StringIndexOutOfBoundsException: String index out of range: -356
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125)
at org.apache.fop.cli.Main.startFOP(Main.java:169)
at org.apache.fop.cli.Main.main(Main.java:200)

- -

java.lang.StringIndexOutOfBoundsException: String index out of range: -356
at java.lang.String.init(String.java:208)
at org.apache.fop.fo.XMLObj.addCharacters(XMLObj.java:217)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.characters(FOTreeBuilder.java:374)
at org.apache.fop.fo.FOTreeBuilder.characters(FOTreeBuilder.java:130)
at
org.apache.xalan.transformer.TransformerIdentityImpl.characters(TransformerIdentityImpl.java:1125)
at org.apache.xerces.parsers.AbstractSAXParser.characters(Unknown 
Source)
at org.apache.xerces.xinclude.XIncludeHandler.characters(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:214)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125)
at org.apache.fop.cli.Main.startFOP(Main.java:169)
at org.apache.fop.cli.Main.main(Main.java:200)



[EMAIL PROTECTED] schrieb:
 Author: adelmelle
 Date: Sun Jun 22 15:10:55 2008
 New Revision: 670422
 
 URL: http://svn.apache.org/viewvc?rev=670422view=rev
 Log:
 Switch FOText to use a java.nio.CharBuffer, and implement the CharSequence 
 interface.
 TextLayoutManager no longer duplicates the char array, operates on the FOText 
 (charAt(i))
 Additionally: endOfNode() for FOText and Character deferred until after 
 white-space handling.
 
 Modified:
 xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/AbstractRetrieveMarker.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/LayoutManagerMapping.java
 
 xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
 xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.java
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIX6rB+Gr+4pk71JwRAgRhAJ4yiAe0sRIc1ez6cVC73PdKaWlRtACdGtyU
cIwGzxNrUfCxhnOXEsaFM6Q=
=vvMe
-END PGP SIGNATURE-

Re: svn commit: r670422 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ layoutmgr/ layoutmgr/inline/ render/rtf/

[Max Berger]

Andreas,

thanks for the quick fix!

Max

Am 23.06.2008 um 20:03 schrieb Andreas Delmelle:



On Jun 23, 2008, at 16:32, Andreas Delmelle wrote:


- Oorspronkelijk bericht -
Van: Max Berger [mailto:[EMAIL PROTECTED]


java.lang.StringIndexOutOfBoundsException: String index out of  
range: -356

at java.lang.String.init(String.java:208)
at org.apache.fop.fo.XMLObj.addCharacters(XMLObj.java:217)
at


Oops! I fixed the exact same thing in FOText yesterday... If you  
look closely at that line in XMLObj.java, you'll see that the  
String constructor is not passed a length/count, but an endIndex.  
I'll look into it ASAP, but this is probably what's causing the  
problem here. FOTreeBuilder.characters() now simply passes the  
length, in any case, so the computation (length - start) makes no  
sense.


I haven't committed the testcase yet (I'll see if I can get to it  
later tonight), but XMLObj has already been fixed, and I don't get  
the error anymore.


Sorry for any inconvenience.

Cheers


Andreas

Re: Check: use of 'short' in TextLayoutManager?

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas,

The JVM converts all shorts to ints before doing any arithmetic, so
shorts are actually a little bit slower than ints.

As for the size: If you have primitive values, an int takes up 4 byte,
whereas a short takes 2 bytes (+java overhead), meaning 100.000 * 3 int
rather than shorts should take up 600kbyte of memory more - hardly
noticeable compared to fops overall memory usage.

When you use the non-primitive types, java = 1.5 uses the flyweight
pattern, meaning there is one instance for every number used, you would
only store a pointer, which has the same size for Integer and Short.

So +1 for making this change.

Max

Andreas Delmelle schrieb:
 
 Hi all
 
 Just checking if anyone would mind terribly if the AreaInfo inner class
 in TextLayoutManager were changed to use 'int' indices rather than 'short'.
 
 AFAIK, this is the only reason we currently need to split up FOText
 instances larger than 32K characters. At the time I introduced this fix,
 I opted to split the FOText instances, since I was a bit concerned about
 a rise in memory consumption. Upon closer inspection, and some browsing
 around, this seems to have far less of an impact than I thought...
 
 I did a quick test, allocating space for an array of 100.000 instances of:
 - a wrapper around three short values (values Short.MAX_VALUE)
 - a wrapper around three int values (values Integer.MAX_VALUE)
 
 The results:
 - 3 shorts - 100.000 instances = (2200K - 800K) = 1600K
 - 3 ints - 100.000 instances = (2980K - 800K) = 2180K
 
 The 800K is subtracted to account for the instance size (8 bytes * 100K).
 
 So three ints do not take up 100% as much space (as I initially
 expected), but only roughly between 30% and 50%...
 
 
 Opinions?
 
 Cheers
 
 Andreas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIW12e+Gr+4pk71JwRAgWoAJwOIDLdgcYEBZQ4Tx0gPZaJe4KAXQCfc+Cs
u2CYsAOxh6HnzLzu81iOH7c=
=WlBi
-END PGP SIGNATURE-

Re: FOText question

[Max Berger]

Andreas,


Am 15.06.2008 um 13:25 schrieb Andreas Delmelle:
Now, while I'm at it, I'm wondering whether it would be a good idea  
to have FOText implement Java 1.4's java.lang.CharSequence  
interface. This would mean that FOText gets a few extra methods  
(charAt(), length() and subSequence()), allowing us to use it in  
other parts of the code in the same fashion as a String or  
StringBuffer. The toString() method would need to be altered to  
follow the  definition as specified in the API docs (i.e. only  
output the text-content).


Any opinions on this? (or more importantly: Any objections?)


Not at all. I am still working my way through the Layout code, trying  
to get the alignmentContext to work, so any reduction / simplification  
in this respect would only make it easier.


As for the implementation of the interface: If the subSequence is  
never used, then it is probably a good idea to implement if by  
throwing an UnsupportedOperationException, as this operation seems  
very complex and there'd be no point implementing it unless it is used.



Cheers
Andreas


Max

Re: Code Quality Metrics

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vincent,

Vincent Hennebert schrieb:
 18000 PMD violations is just sick. Things like rule [1] doesn't really help
 the source code. We can do that if we get a budget for 
 nuclear-power-plant-grade
 software.
 Same here I guess. Now may be the right time to launch the debate,
 actually. I’ll try to gather some energy in the next days for that.

PMD contains many different check sets. The main reason for the large
number of violations is that I've enabled many of the check-sets, among
those optimizations and design, which are responsible for the large
number of error messages. Maybe we should start with the basic set and
go from there?

 [1] 
 http://pmd.sourceforge.net/rules/optimizations.html#MethodArgumentCouldBeFinal

 +1
 I must say, I’ve never really grasped the benefit of doing this. I’d be
 happy to be enlightened, though.

Sure:

Declaring a parameter / variable as final makes it immutable in the
method where it is used. This is:

- - required if the variable is used in an anonymous inner class (as a way
of passing parameters into one)

- - good coding practice on all methods: If a parameter is re-assigned,
the value may not be what the programmer actually intended it to be.

Example:

void someMethod(List l)
{
  if (l==null) l = new LinkedList();
  l.add(test);
}

or even worse, this attempt to fix it:

List someMethod(List l)
{
  if (l==null) l = new LinkedList();
  l.add(test);
  return l;
}

Here we have a very subtle code bug, which is triggered only in a few cases:

List l1;
List l2;
...
l1 = someMethod(l1); // does not trigger
l1 = someMethod(l2); // does trigger

This rule is listed under optimizations, because final can also be
used as a hint for hotspot, and many people use it mostly for
optimization (although the performance advantage is debatable).


Max
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUlXI+Gr+4pk71JwRAsf+AJsEKJgPlO528ArRQ2/QO05Xn0MBvwCfeRAY
VP8QJHJoHsccbd3b40xS7pU=
=/b+s
-END PGP SIGNATURE-

Re: Code Quality Metrics

[Max Berger]

Dear Fop-Devs,

Jeremias is right - you actually need to use the output of these  
reports. At this time there are:


1849 checkstyle violations
18702 pmd violations
possible (find)bugs.

Many of these could be automatically solved using the eclipse  
cleanup tools (which can actually be called on the whole src dir!).  
However, that would result in a change in almost every file, and  
making merging of separate branches almost impossible. This should  
therefore not be done until 0.95 is released, to allow backporting.  
The main question is, should it be done at all?


Max

Am 11.06.2008 um 09:13 schrieb Jeremias Maerki:


I'm using FindBugs (as Eclipse plug-in) for some time now and it is
really good. Not that I can really say yes to 100% of the suggestions.
But about 98%.

I'm not sure about the benefit of those reports. We've had the
Checkstyle report for years now, but I doubt many people look at that
often. Having those tools as IDE plug-ins is much more useful. But  
that

needs to be set up by every dev him/herself.

On 10.06.2008 10:01:03 Max Berger wrote:

Dear Fop-Devs,

since this came up, here is a list of tools I use for software  
quality

checking (and all them them can check for generic list types). All of
them have Eclipse and maven plugins (and ant tasks, and )

Checkstyle: checkstyle.sf.net

(already configured in fop, so nothing needs to be done)

Findbugs: findbugs.sf.net

(very good - all its advices should be followed)

PMD: pmd.sf.net

(contains almost too many rules, some of them are debatable)

I'd be willing to set up reporting for these 3 tools, so that you can
check what they suggest. I usually try to follow of these rules when
creating new files.

Max






Jeremias Maerki

Re: [g...@vmgump]: Project xml-fop (in module xml-fop) failed

[Max Berger]

Jeremias,

I've removed the reference to retroweaver to fix this bug.

What I tried to do was to add the verify task of retroweaver, not  
the weave task. Verify will check if all the classes are available  
in 1.4, which is something we should definitely to, even for the  
current trunk. It was not my intention to do any actual weaving.


My mistake here was not to remove the reference, this happend because  
I was doing these changes offline. In the build-file, as submitted,  
the task was not actually used, just defined.


My main issue here is that I cannot replicate the error message: I've  
tried JDK 1.4, 1.5, and 1.6, and never got this error message. Which  
JDK / ant version does gump run with?


Max

Am 12.06.2008 um 15:16 schrieb Jeremias Maerki:


That's obviously Retroweaver that causes the failure here. The fix in
[1] is easy but: Max, why did you add retroweaver to Trunk while we  
were
not yet in agreement if the experiment should be done in a branch or  
not?

I clearly stated my preference.

[1] https://svn.apache.org/repos/asf/gump/metadata/project/xml-fop.xml

On 11.06.2008 17:24:11 Jeremias Maerki wrote:

To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 33 runs.
The current state of this project is 'Failed', with reason 'Build  
Failed'.

For reference only, the following projects are affected by this:
   - xml-fop :  XSL-FO (Formatting Objects) processor


snip/

BUILD FAILED
/srv/gump/public/workspace/xml-fop/build.xml:460: taskdef class  
net.sourceforge.retroweaver.ant.RetroWeaverTask cannot be found

snip/


Jeremias Maerki

List vs. LinkedList

[Max Berger]

Dear Fop-Devs,

as far as I can tell, there where two issues with my cleanups  
yesterday: Readablility and Performance.


I've just submitted a patch which adds a ListUtil class, to make the  
code more readable again. I've replaced (hopefully) all occurrences of  
size() - 1 with the call to these utils. Since they are static the  
hotspot engine will pick them up and inline them very nicely, so there  
should be no performance overhead.


I hope this addresses the readability issue.

Performance  of list.get(list.size()-1). In the default implementation  
of LinkedList ( sun jdk), there is no performance penalty for this  
call. The list is linked from both ends, and all calls to an element   
size()/2 are searched from the back. There is a small overhead, since  
we now have two virtual method calls instead of one, again something  
that hotspot can iron out very nicely.


Also: Calls to interface methods are not slower than calls to the  
class directly: In both cases the virtual method table is consulted,  
as class methods are overridable. The only exception is if the class  
method or the class is declared final: Then the compiler may optimize  
the calls.


I've also noted:

There are a lot of list.size()  0 calls. I've replaced the ones in  
the touched files with .isEmpty(), which is more performant.


Max

Code Quality Metrics

[Max Berger]

Dear Fop-Devs,

since this came up, here is a list of tools I use for software quality  
checking (and all them them can check for generic list types). All of  
them have Eclipse and maven plugins (and ant tasks, and )


Checkstyle: checkstyle.sf.net

(already configured in fop, so nothing needs to be done)

Findbugs: findbugs.sf.net

(very good - all its advices should be followed)

PMD: pmd.sf.net

(contains almost too many rules, some of them are debatable)

I'd be willing to set up reporting for these 3 tools, so that you can  
check what they suggest. I usually try to follow of these rules when  
creating new files.


Max

Re: Switching to Java 1.5

[Max Berger]

Vincent,


Am 09.06.2008 um 20:01 schrieb Vincent Hennebert:

There’s a point that I’d like to further discuss: why wouldn’t we
implement Retroweaver/Retrotranslator in the Trunk? If we go the
cautious route, that is if we run the test suite on a 1.4 jvm after  
each
introduction of a 1.5 feature and before committing the change, I  
don’t
see what’s the problem. Doing it in a branch more or less boils down  
to

not doing it at all IMO... Or this would be a very short-lived branch
(no more than a few weeks), just the time to test
Retroweaver/translator.


Just saw that retroweaver contains verification against a 1.4 jdk if a  
classpath is given  (e.g. a 1.4 jdk is installed). We could add this  
to the build path and require commiters to have a 1.4 jdk installed,  
and call verification during the build phase. This would actually be  
an advantage over the current situation, where 1.5 specific code (new  
methods) are sometimes added accidentally.


Maybe we can start with just the verification an no retroweaving just  
yet?





Thanks,
Vincent



Max

ElementListUtils vs. ListUtils

[Max Berger]

Dear Fop-devs,

as I prepared the patch while being offline, I had not read the  
suggestion to put the code I put in ListUtil into  
ElementListUtils. Just to be on the safe side: Should both classes  
be merged? Or is elementListUtil specific to ListElement ?


Max

Re: Code Quality Metrics

[Max Berger]

Dear Fop-Devs,

for the actual implementation, I think it would be a good idea to  
create a second lib-directory (e.g. buildsupport, or buildlib), and  
add the required libs there, so that we're all using the same tools.  
These libs would only be needed during build, and not during deployment.


Libs which are BSD (pmd, retroweaver /translator) would be added there  
directly, for others (checkstyle, findbugs)  I'd provide a readme on  
where to find them.


Right now this is the case with lib/, but everything in lib/ is also  
used during run-time, whereas I would explicity like to exclude these  
build-time dependencies.


This would increase the size of the fop svn directory, but it would  
also make it easier for developers to get started.


Please comment.

On that note, I'm currently evaluating IntelliJ, which has some  
really nice Code Inspection features. It warns about redundant  
statements, for example: unnecessary casts, variable that are  
assigned but never used, while-statements that don't loop...


nice. This could definitely be complimentary.


As you said, the result could turn out to be scary... :-)


It will be.


Cheers
Andreas


Max

Re: svn commit: r665699 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/table/ layoutmgr/ layoutmgr/inline/ layoutmgr/list/ layoutmgr/table/

[Max Berger]

Jeremias,

actually I had the same reservations (especially about the last  
element, and if you have a real problem with this feel free to revert  
this patch. Maybe we could write a simple helper method instead?


static Element getLastElement(List l) ?

Would that disperse your concerns?

Why I did it: For the exact reason that the interface is more  
convenient. You are only partially right that LinkedList is the most  
efficient interface: I was digging through the LayoutCode, and found  
places where a single element list is created:


LinkedList l = new LinkedList()
l.add(element)
return l.

In this case, Collections.singletonList() is MUCH more effective.  
AAMOF, on all list where you know the size beforehand (most cases in  
the layout, becasue you know that x elemnets are going to result in x  
layoutElements) arrayList is more effective.



Background: I discovered that passing back multiple LayoutContexts is  
not as easy as I thought, and I need to do some refactoring in the  
layout code to ensure this is possible - therefore this (and the last  
cleanup). I really need to make the code easier to read before I can  
change it.


Max


Am 09.06.2008 um 16:40 schrieb Jeremias Maerki:

Frankly, I'm less than thrilled. I appreciate the good will behind  
this
but I'd have appreciated some advance warning, too. My concern is  
that:

-ListElement last = (ListElement)contentList.getLast();

is much easier to read and write than:

+ListElement last = (ListElement) contentList
+.get(contentList.size() - 1);

When working with element lists constructs like the above are  
everywhere.
A linked list IS the most efficient data structure for element  
lists. I

generally support using the generic type instead of the specific class
(i.e. List instead of ArrayList), but LinkedList is adding some often
used methods for element lists which improve code readability. I'm
curious what other committers think about this.

On 09.06.2008 16:25:29 Adrian Cumiskey wrote:
This is really good Max, really appreciate what you are trying to  
do here.  It must have been quite

boring and laborious...  but great cleanup work :).

[EMAIL PROTECTED] wrote:

Author: maxberger
Date: Mon Jun  9 07:15:38 2008
New Revision: 665699

URL: http://svn.apache.org/viewvc?rev=665699view=rev
Log:
Replaced LinkedList with generic List interface


snip/

Jeremias Maerki

Re: Switching to Java 1.5

[Max Berger]

Dear  Fop Devs,

I use retrotranslator for another project which has to run on specific  
version of scientfic Linux, where only Java 1.4 is installed.


There are two steps for using retrotranslator:
- Use NO 1.5 classpath features, just generics: Works very well with  
retrotranslator
- Use other 1.5 classpath features: Warning: AutoBoxing is part of  
this, since it uses the new Integer.valueOf() methods, which are not  
in 1.4. In this case, Fop would have to be distributed with the  
retrotranslator-runtime, which is 300kb


Retrotranlator-runtime contains many backports for common librarys,  
such as java.util.concurrent.


One thing is does not support (which made it unusable for other  
projects, such as JEuclid is the new high-plane unicode support in  
java 1.5. This would also be VERY interesting for fop, and i'd be a  
pitty not to use it).


Retroweaver and retrotranslator both provide similar functionality. I  
just chose retrotranslator because there is a maven plugin :)


I think in the long term this would be a good strategy for a soft move  
to 1.5, but I would like to ensure fop 0.96 works with 1.4


+1

Max

Am 05.06.2008 um 18:32 schrieb Adrian Cumiskey:

I would imagine that the availability of binary 1.4 compatibility  
should be enough for most users.


I don't see how there should be any problems so long as we continue  
to try and use the Java 1.4 libraries and the generics features of  
1.5.  I have tested out Retroweaver briefly in the past and it  
seemed to work well, but it would interesting to hear from anyone  
who has any hands on experience with using it.


+1 from me.

Adrian.

Vincent Hennebert wrote:

Hi Guys,
I would like to raise this topic again: what about switching to  
Java 1.5

as a minimum requirement?
The End of Life transition period for Java 1.4 will end on the 30th  
of
October 2008 [1]. The next version of FOP (after 0.95) will  
probably not
have been released by this time, so we could start using 1.5  
features in

the Trunk.
[1] http://java.sun.com/j2se/1.4.2/download.html
I don’t particularly expect any disagreement from a developer point  
of

vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.
According to the poll Jeremias made in October 2007 [2], only 14.3%  
of
the users would think it’s a bad idea to switch to 1.5. A year  
later the

percentage will probably have further decreased.
[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
I guess a new poll will still be necessary. Or we could base it on  
lazy

consensus: “If you still want Java 1.4 compatibility, speak up now!”.
Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I’m  
mainly

thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It’s BSD licensed, so IIC there wouldn’t be any problem to  
distribute it

with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven’t personally tested it, but I’m told it’s working  
pretty

well and it seems to be well maintained. Of course I’d volunteer to
introduce it into the build system and see how it works. FWIW, it’s
based on the ASM library, that I’ve had the opportunity to play with
a few years ago, and what I can say is that it’s a really nice,  
strong,

lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/
Obviously we wouldn’t switch everything to 1.5 immediately. We  
would do
it progressively, when fixing bugs or implementing new features. So  
it

should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we  
could

restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we  
could

stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).
Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable,  
more

easily maintainable, etc. I can’t wait anymore to use those features.
So, WDYT?
Thanks,
Vincent

Re: svn commit: r660998 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/standard-testcases/

[Max Berger]

Andreas,

just to follow up and show that I have not forgotten your recent  
email :)


Am 29.05.2008 um 19:01 schrieb Andreas Delmelle:

There is still an open issue: When the font is changed, the metrics
for the line are not. E.g. when i have something like

test SIGMA test
fo:blocktest  #x2211; test/fo:block

the SIGMA character is set lower than it should be. At this time I  
was
unable to find the cause of this behavior. Maybe someone has a hint  
as

to why this happens?


To further investigate, compare the behavior with:

fo:blocktest  fo:inline font-family=Symbol#x2211;/fo:inline  
test/fo:block
fo:blocktest  fo:character font-family=Symbol  
character=#x2211; / test/fo:block


The fo:inline or fo:character trigger the creation of a new  
org.apache.fop.layoutmgr.inline.AlignmentContext, which is taken  
into account by the LineLayoutManager associated to the fo:block.
That context is used to determine the alignment point for the  
content of the fo:inline vis-à-vis the dominant-baseline of the  
enclosing line.


The above would expand to:

fo:block alignment-adjust=auto
 alignment-baseline=auto
 baseline-shift=baseline
 dominant-baseline=auto
 test  fo:inline font-family=Symbol
 alignment-adjust=auto
 alignment-baseline=auto
 baseline-shift=baseline
 dominant-baseline=auto#x2211;/fo:inline test
/fo:block

(analogously for the fo:character)

Strictly following the XSL-FO Rec, the behavior for the initial  
sample should be identical to using a fo:character, so most likely,  
something similar should happen when the font is switched in the  
TextLayoutManager internally. TextLayoutManager.AreaInfo does not  
carry a reference to any AlignmentContext like  
LeafNodeLayoutManager.AreaInfo. Instead the used AlignmentContext is  
always the one passed by the parent.
(see TextLayoutManager.getNextKnuthElements(), third line in the  
method:

 alignmentContext = context.getAlignmentContext()


This is definitely the right place, thanks for pointing this out!



 - that context is used in addElementsForAWordFragment() when  
creating the corresponding KnuthInlineBox)


If we can simply make sure that each box gets the alignment context  
appropriate for the font used for the word-fragment, that should  
suffice.
This could be done either by passing the AlignmentContext via the  
AreaInfo, as is done in the superclass, or by having the TextLM hold  
a reference to a collection of AlignmentContexts (one for each  
effectively used font), and use the appropriate one when creating  
the boxes.


I tried this, and it failed. At this point, there are too many  
variables called aligmnmentContext. The superclass (LeafNodeManager)  
has one, TextLayoutManager has one, and LNM has a function  
makeAlignmentContext which is supposed to be overridden to supply a  
new AlignmentContext. This is confusing and needs to be cleaned up.  
I'll try investigating here.


I've tried modifying the alignmentContext by creating a child algnment  
context, and even by creating a direct clone (copying of all  
attributes) of the parent alignment context, and it always failed the  
testsuite. So at this point I belive there are some calles to setters  
which throw it off.



HTH!

Cheers

Andreas


Max

Re: svn commit: r660998 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/standard-testcases/

[Max Berger]

Dear Fop-devs,

Just some comments on this work:

- it implements a word-by-word selection as the auto font-selection
strategy. It will always pick the first font, which is able to display
the most characters in a word. This behavior needs to be documented
(I'll do that)
- character-by-character is still TDB. I am currently thinking about
creating breaks within one word if the font changes, then most of this
implementation could be reused (and a font-change is a break in the
word anyways)

There is still an open issue: When the font is changed, the metrics
for the line are not. E.g. when i have something like

test SIGMA test
fo:blocktest  #x2211; test/fo:block

the SIGMA character is set lower than it should be. At this time I was
unable to find the cause of this behavior. Maybe someone has a hint as
to why this happens?

Max

2008/5/28  [EMAIL PROTECTED]:
 Author: maxberger
 Date: Wed May 28 09:10:32 2008
 New Revision: 660998

 URL: http://svn.apache.org/viewvc?rev=660998view=rev
 Log:
 Implemented Font auto-selection word-by-word

Re: ZapfDingbats and Symbol not found whereas they are not needed

[Max Berger]

Andreas,

indeed. To support proper character auto-selection I've modified the  
default to include the symbol and zapf-dingbats fonts, as they contain  
many characters normally not found in the default fonts.


I hope I'll have time to continue this work soon (can't promise  
anything atm)


Max

Am 27.05.2008 um 17:23 schrieb Andreas Delmelle:


On May 27, 2008, at 17:05, Vincent Hennebert wrote:


If I run FOP Trunk on the attached FO file, I get the two following
warnings:
WARNING: Font Symbol,normal,700 not found. Substituting with  
Symbol,normal,400.
WARNING: Font ZapfDingbats,normal,700 not found. Substituting  
with ZapfDingbats,normal,400.


Seems to be a result of Max changing the default value for the font- 
family property (see r655281)


Cheers

Andreas

Font-Selection strategies (Re: svn commit: r655281 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/FOPropertyMapping.java src/java/org/apache/fop/layoutmgr/inline/CharacterLayoutManager.java s

[Max Berger]

Andreas,


Am 11.05.2008 um 16:25 schrieb Andreas Delmelle:
Support character-by-character font-selection strategy on  
fo:character element


Good thinking!
FWIW, I've also been thinking in a similar direction, but maybe a  
bit more generic, as utility method in the FontManager maybe (?)


yes, indeed. See the TODO comment in the code. The reason I  
implemented it there were:

- proof-of-concept
- had no idea where it would really belong

The piece of code that you moved to a separate method here here was  
indeed a temporary solution of my moving this logic out of the FO  
tree, since I feel it did not really belong there. I just needed to  
get the same behavior as before, when it was housed in CommonFont,  
which always returned the first font-family in the list.


Thanks for that! This really helped getting this started


+private Font selectFontForCharacter(Character fobj) {


Now that we have a FontManager, what if we add something to it like:

public Font selectFontForCharacter(FontTriplet[] triplets, char, int)


+1, what would be the int be for?

That way the loop in question finally moves to where I think it  
actually belongs... and a similar approach could then be applied to  
the TextLayoutManager. As an initial step, we could already make  
sure that the selected font is always one that can display the first  
character.

I don't like a partial implementation (the first character version)

For the textlayoutmanager: I saw that similar functionality in  there  
multiple times, for paragraphs, page-references, etc.  They all seem  
to create the same result, just based on content (paragraph) or  
context (page-references). So the first step here would be to refactor  
the common functionality out as well.


Now the real question is about the possible font selection stragety.  
We'd have to implement auto and characte-by-character


they are defined as follow:
auto: is vendor-specific, but should use a broader context
char-by-char: select first font-match for evey character.

First the question is about line metrics: In a paragraph, we could use
- the line metrics for the font of the first char for the whole  
paragraph - easiest implementation, but the result may look bad
- the line metrics of all fonts used in a line (I have no idea how  
that would work) - best result
- the line metrics maximia for all fonts used in a paragraph (medium  
to implement, medium result)


the next question is: what is auto-selection strategy?

would it be:
- select font based on the first character? now that i think about it,  
I really like it - it would be really fast, and produce a correct  
result IF the symbols are enclosed in their own fo:block

- select a font that can display the whole paragraph (if possible)
- switch for every word? This would probably give good results, but  
may not make so much difference to char-by-char.
- make it the same as character-by-character? This would possibly be  
slower, and produce some overhead, so its a bad idea for default  
behavior.


hope this makes sense.



Andreas


Max

Re: Q: Font-cache refresh warning?

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Fop-Devs,

just thinking about that (because oner emailed me i got this font-cache
error when running fop 0.95)

maybe this could be reworded?

as: level: info
Discarding Font-Cache from different fop version

warning imo should only be used when the output changes, in this case
performance is the only loss.

Max

Andreas Delmelle schrieb:
 On May 8, 2008, at 02:35, Adrian Cumiskey wrote:
 
 If you update your local sandbox it should now fix itself the next
 time you compile and run.
 
 Yep, already done. Thanks for the quick intervention!
 
 Cheers
 
 Andreas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIw03+Gr+4pk71JwRAtfeAJ0aVtv5LzxRrgTYdcaTXWHy/1K+0QCdG0bb
sNNhbGAeG64bf1tQzQXq8Hg=
=ja0A
-END PGP SIGNATURE-

Re: [VOTE] Merge Temp_ProcessingFeedback branch into Trunk

[Max Berger]

Jeremias,


On Sam, 2008-04-05 at 16:33 +0200, Jeremias Maerki wrote:
 As announced three days ago, I'd like to call for a vote to merge the
 processing feedback branch [1] into Trunk. This will add the new
 per-processing-run event subsystem to FOP that has been described on:
 http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
 
 [1] 
 https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ProcessingFeedback

The new system will only be thoroughly tested if used, so now is the
time.

+1


mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Supporting unusual encodings for Type 1 fonts

[Max Berger]

Jeremias,

just tested on Linux with evince 2.20.2 and acrobat reader 7.0. The
results are the same as the one shown in your explanations. The
improvement is clearly visible. Good work!


Screenshots are available at:

http://max.berger.name/tmp/fop/


On Fre, 2008-02-29 at 16:14 +0100, Jeremias Maerki wrote:
 For those, who want to test PDF viewer compatibility I have a demo PDF
 which demonstrates Type 1 step 2 implemented with solution 2 (multiple
 descendant fonts with dynamic encoding build-up).
 
 http://people.apache.org/~jeremias/fop/type1-demo/
 - [1] font-type1-demo-before.pdf (revision 627678, before I added the AFM 
 stuff, i.e. step 1)
 - [2] font-type1-demo-step1.pdf (current FOP Trunk HEAD)
 - [3] font-type1-demo-step2.pdf (my local working copy)
 

 Jeremias Maerki


mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: svn commit: r629902 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/cli/InputHandler.java status.xml

[Max Berger]

Jeremias,

give me two days... If i haven't found a java 1.4 compatible version on
sunday feel free to revert the patch. Afaik setting some properties on
the SAXparser should have the same effect.

Max


On Fre, 2008-02-22 at 14:37 +0100, Jeremias Maerki wrote:
 Hmm. Now this is one of those cases where we have to be careful. With
 this change FOP doesn't compile on Java 1.4 without putting a JAXP 1.3
 in jre/lib/endorsed directory or using the -Xbootclasspath argument.
 And those running it will have the same problem. If we really want to do
 this, putting the XML JARs (including xml-apis(-ext).jar) into
 fop/lib/endorsed will make things easier. And maybe we should dedicate
 a special page in our docs on this topic.
 
 On 21.02.2008 19:22:23 maxberger wrote:
  Author: maxberger
  Date: Thu Feb 21 10:22:22 2008
  New Revision: 629902
  
  URL: http://svn.apache.org/viewvc?rev=629902view=rev
  Log:
  Turned on XInclude processing for the main source given on the command line.
  
  Modified:
  xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
  xmlgraphics/fop/trunk/status.xml
  
  Modified: 
  xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
  URL: 
  http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java?rev=629902r1=629901r2=629902view=diff
  ==
  --- xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java 
  (original)
  +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java Thu 
  Feb 21 10:22:22 2008
 snip/
  +Source result;
  +try {
  +InputSource is = new InputSource(new FileInputStream(
  +this.sourcefile));
  +SAXParserFactory spf = SAXParserFactory.newInstance();
  +spf.setNamespaceAware(true);
  +spf.setXIncludeAware(true);
  +XMLReader xr = spf.newSAXParser().getXMLReader();
  +result = new SAXSource(xr, is);
  +} catch (SAXException e) {
  +result = new StreamSource(this.sourcefile);
  +} catch (IOException e) {
  +result = new StreamSource(this.sourcefile);
  +} catch (ParserConfigurationException e) {
  +result = new StreamSource(this.sourcefile);
  +}
  +return result;
 snip/
 
 
 
 Jeremias Maerki
 
mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: svn commit: r630215 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java

[Max Berger]

Jeremias,

this should do it. Although it restricts XInclude processing to xerces
based parsers. However, that should not be a problem since xerces is
shipped with fop anyways.

Please note that at I was not able to test with a real 1.4 JDK though.

Max

On Fre, 2008-02-22 at 14:17 +, [EMAIL PROTECTED] wrote:
 Author: maxberger
 Date: Fri Feb 22 06:17:20 2008
 New Revision: 630215
 
 URL: http://svn.apache.org/viewvc?rev=630215view=rev
 Log:
 Fixed backward compatiblity with 1.4
 
 Modified:
 xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
 
 Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
 URL: 
 http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java?rev=630215r1=630214r2=630215view=diff
 ==
 --- xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java 
 (original)
 +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java Fri 
 Feb 22 06:17:20 2008
 @@ -151,8 +151,8 @@
  InputSource is = new InputSource(new FileInputStream(
  this.sarg1ourcefile));
  SAXParserFactory spf = SAXParserFactory.newInstance();
 -spf.setNamespaceAware(true);
 -spf.setXIncludeAware(true);
 +spf.setFeature(http://xml.org/sax/features/namespaces;, true);
 +spf.setFeature(http://apache.org/xml/features/xinclude;, true);
  XMLReader xr = spf.newSAXParser().getXMLReader();
  result = new SAXSource(xr, is);
  } catch (SAXException e) {
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: svn commit: r630215 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java

[Max Berger]

Jeremias,

which is taken care of, as this is a subclass of SAXException. In this
case the old behavior will be triggered. 

...
   } catch (SAXException e) {
result = new StreamSource(this.sourcefile);
} catch (IOException e) {
...

Max

On Fre, 2008-02-22 at 15:24 +0100, Jeremias Maerki wrote:
 Sorry, Max, but it's not that simple. The GNU or Oracle XML parser will
 throw a SAXNotRecognizedException here.
 
 On 22.02.2008 15:17:20 maxberger wrote:
  Author: maxberger
  Date: Fri Feb 22 06:17:20 2008
  New Revision: 630215
  
  URL: http://svn.apache.org/viewvc?rev=630215view=rev
  Log:
  Fixed backward compatiblity with 1.4
  
  Modified:
  xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
  
  Modified: 
  xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
  URL: 
  http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java?rev=630215r1=630214r2=630215view=diff
  ==
  --- xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java 
  (original)
  +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java Fri 
  Feb 22 06:17:20 2008
  @@ -151,8 +151,8 @@
   InputSource is = new InputSource(new FileInputStream(
   this.sourcefile));
   SAXParserFactory spf = SAXParserFactory.newInstance();
  -spf.setNamespaceAware(true);
  -spf.setXIncludeAware(true);
  +spf.setFeature(http://xml.org/sax/features/namespaces;, true);
  +spf.setFeature(http://apache.org/xml/features/xinclude;, 
  true);
   XMLReader xr = spf.newSAXParser().getXMLReader();
   result = new SAXSource(xr, is);
   } catch (SAXException e) {
  
  
 
 
 
 Jeremias Maerki
 
mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Q: What should happen when an image is not found?

[Max Berger]

Dear Fop devs,


On Mit, 2008-02-20 at 10:24 +, Vincent Hennebert wrote:
  A PI could mean: From this point on in the whole document.
  HOWEVER: If fop currently uses no PIs (I am not sure about this), then
  it should be a fox: extension, to make all behavior similar.
  
  Indeed, we don't use PIs at the moment. And I'm not sure we should. I
  wonder how many people know how to work with them.

Probably very few - and if fop does not use them, it is not consistent
to start using them.

 
 Adrian made the suggestion some time ago of using the fo:declarations 
 element to override configuration on a per-document basis:
 http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200801.mbox/[EMAIL
  PROTECTED]

This idea sounds really reasonable and consitent. Please note however,
that XSL fo specified (color-profile)+ as content for fo:declarations at
some point, which would make some documents non-conformant. So +1 for
this one :)

  As for the size: 
 
  - Always use the size given if given.
 
  Either:
  - a 0.0001 x 0.0001 pt empty transparent image OR
  
  Would have to be at least 0.001x0.001pt as this is our minimal
  resolution. ;-) Feels very HTML-like...
  
  - A missing image image, about 1x1 cm: should have a border and a red
  x (as seen in web browsers, etc.)
  
  I think I'd prefer this. It's still a change in FOP's behaviour. But so
  many people don't read or ignore FOP's log output, visual feedback is
  probably a good idea.
 
 +1

ok, sounds good. +1

 Vincent

mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Q: What should happen when an image is not found?

[Max Berger]

Dear Fop Devs,

i think this was the original intention of a processing instruction. I
really do not see clearly where fox:fail-on-missing-image would go in
the fo tree. A PI could mean: From this point on in the whole document.
HOWEVER: If fop currently uses no PIs (I am not sure about this), then
it should be a fox: extension, to make all behavior similar.

As for the size: 

- Always use the size given if given.

Either:
- a 0.0001 x 0.0001 pt empty transparent image OR
- A missing image image, about 1x1 cm: should have a border and a red
x (as seen in web browsers, etc.)


On Mon, 2008-02-18 at 07:47 -0800, The Web Maestro wrote:
 That all sounds good. As for the extension vs. Config approach, the
 config could specify the default behavior  users could override it
 via individual fox:image-missing-behavior (or
 fox:fail-on-missing-image or something). If there's no
 @fox:[image-missing-behavior] specified, it'll do the config setting
 or log a warning if nothing specified.
 
 Clay

mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Remove deprecated methods in outer API for 0.95?

[Max Berger]

  For some time now we have a number of methods in our outer API that are
  deprecated. I think we should remove them now. Anyone against my doing
  that as part of the preparations for the release?

AFAIK it is good practice to keep a deprecated API for at least 1
release, so I'd say +1 for anything that has been marked deprecated in
the 0.94 release and earlier.

Max

Repository properties?

[Max Berger]

Dear Fop devs,

I'd like to make some property changes in svn:

On all java files:
- set svn:eol-style native
- set svn:keywords Author Date Id Revision

supply a .sh script fixproperties.sh in the root dir which does this
automatically (should  be run from time to time)

On hyph
ignore *.xml

To be discussed:
on *xml
- set svn:eol-style native

Note that something similar has been discussed for xmlgraphics [1].

Please let me know if you see a problem.

[1] 
http://mail-archives.apache.org/mod_mbox/xmlgraphics-general/200707.mbox/[EMAIL 
PROTECTED]

Max

Re: Supporting unusual encodings for Type 1 fonts

[Max Berger]

Jeremias,


2008/2/12, Jeremias Maerki [EMAIL PROTECTED]:
 + Higher compatibility with PDF viewers which are not yet
   feature-complete.

would it be possible to create a quick PDF file with these extensions
so that I can test my favorite PDF viewers? As far as I am concerned
these are

- Adobe Acrobat Reader. This is the main app, and it should be tested
with 6, 7, and 8. Having broken pdf on any of those is a real
show-stopper.
- Apple QuickView
- Evince

We could set up a Wiki Test site, and I can try and test the pdf with
different versions of the software to see what exactly the impact is,
and then make a decision based on that.

 Jeremias Maerki


Max

Namespaces for attributes in instream objects

[Max Berger]

Dear Fop-Devs,


I've just recently encountered a possible bug in the jeuclid plugin
for fop. A complete .fo file is added at the end of the mail.

In this file there is a foreign math object:
fo:instream-foreign-object
  mml:math
mml:mstyle mathsize=6pt
  mml:mix/mml:mi
/mml:mstyle
  /mml:math
/fo:instream-foreign-object,

which, as you can see, uses the mathsize attribute. HOWEVER, the
attribute gets ignored, because it is in the default namespace, and only
the attributes in the mml namespace are actually processed by the
plugin. So the above needed to be fixed to:

mml:mstyle mml:mathsize=6pt
  mml:mix/mml:mi
/mml:mstyle

to work properly.

So here are my questions:

- Is this indeed the expected behavior? It seems unintuitive.
- If it is, should it be? Should the plugin not also process attributes
from the default namespace?
- If it is not, where do i need to start looking for the bug? Jeuclid
completely ignores namespaces in attributes, so it is either in the
fop/plugin interface, fop itself, or the xerces parser?


Thanks

Max

---

?xml version=1.0?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
 xmlns:mml=http://www.w3.org/1998/Math/MathML;
 font-size=10pt
  fo:layout-master-set
fo:simple-page-master master-name=page
  fo:region-body region-name=flow/
/fo:simple-page-master
  /fo:layout-master-set
  fo:page-sequence master-reference=page
fo:flow flow-name=flow
  fo:block
Normal
fo:instream-foreign-object
  mml:math
mml:mix/mml:mi
  /mml:math
/fo:instream-foreign-object,
small
fo:instream-foreign-object
  mml:math
mml:mstyle mathsize=6pt
  mml:mix/mml:mi
/mml:mstyle
  /mml:math
/fo:instream-foreign-object,
big
fo:instream-foreign-object
  mml:math
mml:mstyle mathsize=24pt
  mml:mix/mml:mi
/mml:mstyle
  /mml:math
/fo:instream-foreign-object
  /fo:block
/fo:flow
  /fo:page-sequence
/fo:root

Re: Next release - when?

[Max Berger]

Dear Fop Devs,

I think we are mixing two ideas here:

One idea (1) was to release 0.95rc, and then two weeks later 0.95

The other idea (2) is to release 0.95 and call it 0.95rc instead of 0.95beta.

(1) I think makes sense. It would mean after releasing the rc there
would be a short phase (2 weeks) where only bugfixed could be
commited. This is a good idea anyways. +1

(2) The traditional dev steps are alpha - beta - final. Some companies
use Release Candidate to make their beta-phase sound nicer. I strongly
disagree of the use of this word without actually meaning it - as long
as this is not a feature-complete version of fop 1.0 I'd vote -1 for
calling it rc.

Btw: Other projects, such as GNOME and eclipse have a strong
time-based release plan. Maybe this would be a good idea for the fop
project as well? It would give users (and plugin developers) more
certainty about whats going on.



Max


2008/1/11, J.Pietschmann [EMAIL PROTECTED]:
 Jeremias Maerki wrote:
  So, what about a 0.95 beta?
 
  Like Chris, I'd prefer calling it a release candidate, but +1 to the
  general idea.

 I like the idea of an release candidate too.

 J.Pietschmann

Re: Disable 900 penalty when not all cells have contributed in tables?

[Max Berger]

Vincent,

  both of them I'd prefer to see split onto two pages. So imo a high
  penalty is better
 That will still be possible with the infinite penalty (assuming your
 1.5 pages contain enough break possibilities in between). The rule
 here is only to make sure that every column contributes at least the
 content before the first break possibility (for each column) to a row
 before the row is considered breakable.

In this case +1, I can't think of any other cases where this could fail.

   When a row starts at the bottom of a page, there may not be enough 
   remaining room to allow every cell to put a part of its content:
   
   | Cell 1   |   |
   
   - Page break ---
   
   |  | This text doesn’t fit |
   |  | on the previous page  |
   
   


Max

Re: svn commit: r607188 - /xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/fo/FOTreeBuilder.java

[Max Berger]

Jeremias,

not that fop is on 1.4: AFAIK this is what assert statements are for:
Add checks for things which *should not happen*, such as contract
violations.

Max

On Mon, 2008-01-07 at 09:21 +0100, Jeremias Maerki wrote:
 It could be null if the caller violates the ContentHandler contract. The
 question should be: Should we validate the ContentHandler contract with
 check code of our own? But that's an academic question because the check
 is barely noticeable at runtime.
 
 On 02.01.2008 12:18:18 Vincent Hennebert wrote:
  Hi,
  
   URL: http://svn.apache.org/viewvc?rev=607188view=rev
   Log:
   Throwing IllegalStateException causes a prior exception to be swallowed 
   by Xalan-J. Need to throw a SAXException instead.
   Instead of logging an error about the element mismatch throw a 
   SAXException because the logging only confuses the user as it's 
   practically always a follow-up exception of an exception happening 
   earlier in the respective startElement() event.
   Modified: 
   xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/fo/FOTreeBuilder.java
  snip/
   +/** [EMAIL PROTECTED] */
public void endElement(String uri, String localName, String 
   rawName)
throws SAXException {
if (currentFObj == null) {
  
  How can currentFObj be null in the first place? Normally it was set in 
  the previous startElement event (or a ValidationException has been throw 
  anyway)?
  
  Vincent
  
  
  -- 
  Vincent HennebertAnyware Technologies
  http://people.apache.org/~vhennebert http://www.anyware-tech.com
  Apache FOP Committer FOP Development/Consulting
 
 
 
 
 Jeremias Maerki
 

Re: FOP and XML Graphics Commons Maven artifacts

[Max Berger]

Cameron,


On Fre, 2007-12-07 at 08:14 +1100, Cameron McCormack wrote:
  Letting the maven deploy plugin create the correct directory structure
  and needed files is MUCH easier than trying to do this yourself in ant.
  I would therefore recommend the use of maven to deploy the maven
  artifacts.
 
 Understood.  BTW, I see that
 http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlgraphics/fop/maven-metadata.xml
 doesn’t mention the 0.93 release in the versions element (and the same
 for XML Graphics Commons 1.1).  Is that a problem?

I am not sure, but I've fixed it for both of them.

  For the -jdk1.3 versions, i propose to add -jdk13 to the version, e.g.
  
  groupIdorg.apache.xmlgraphics/groupId
  artifactIdxmlgraphics-commons/artifactId
  version1.2-jdk13/version
  
  and respective for fop. 
 OK.  I will do the same for Batik then.

one slight caveat:
* the -jdk13 artifacts should be submitted first, otherwise the
maven-metadata has to be edited to use the version without -jdk13 as the
latest (and then the checksums have to be updated as well)

The real question is whether 1.3 maven artifacts need to be submitted,
as maven itself requires 1.4 to work?


Max


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: svn commit: r602125 - in /xmlgraphics/fop/trunk: lib/ src/java/org/apache/fop/render/ test/resources/META-INF/ test/resources/fonts/

[Max Berger]

Dear Fop-Devs,

this is my first commit, feel free to take it apart :)
One thing that is missing is the actual testcase - I think it belongs  
into test/config/test_fonts_autodetect.xconf, but I have no idea what  
the correct syntax is - DejaVu LGC Serif should be available if  
everything worked fine.


Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC

For information about me or my projects please see http://max.berger.name


Am 07.12.2007 um 16:36 schrieb [EMAIL PROTECTED]:


Author: maxberger
Date: Fri Dec  7 07:36:53 2007
New Revision: 602125

URL: http://svn.apache.org/viewvc?rev=602125view=rev
Log:
Updated xmlgraphics from SVN
Added autodetection of fonts in jar files (x-font and x-font-truetype)
Added files needed for testcase
Please note: Actual testcase is still missing!


Added:
   xmlgraphics/fop/trunk/test/resources/META-INF/
   xmlgraphics/fop/trunk/test/resources/META-INF/MANIFEST.MF
   xmlgraphics/fop/trunk/test/resources/fonts/DejaVuLGCSerif.LICENSE
   xmlgraphics/fop/trunk/test/resources/fonts/DejaVuLGCSerif.ttf
(with props)

Modified:
   xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar
   xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ 
PrintRendererConfigurator.java


Modified: xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar
URL: 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar?rev=602125r1=602124r2=602125view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==

Binary files - no diff available.

Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ 
PrintRendererConfigurator.java

URL: 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/PrintRendererConfigurator.java?rev=602125r1=602124r2=602125view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ 
PrintRendererConfigurator.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ 
PrintRendererConfigurator.java Fri Dec  7 07:36:53 2007

@@ -50,6 +50,7 @@
import org.apache.fop.fonts.autodetect.FontFileFinder;
import org.apache.fop.fonts.autodetect.FontInfoFinder;
import org.apache.fop.util.LogUtil;
+import org.apache.xmlgraphics.util.ClasspathResource;

/**
 * Base Print renderer configurator (mostly handles font  
configuration)

@@ -159,6 +160,16 @@
} catch (IOException e) {
LogUtil.handleException(log, e, strict);
}
+
+// load fonts from classpath
+ 
addFontInfoListFromFileList(ClasspathResource.getInstance()
+.listResourcesOfMimeType(application/x- 
font),

+fontInfoList, fontResolver, fontCache);
+addFontInfoListFromFileList(
+ClasspathResource.getInstance()
+.listResourcesOfMimeType(
+application/x-font- 
truetype),

+fontInfoList, fontResolver, fontCache);
}

// directory (multiple font) configuration

Added: xmlgraphics/fop/trunk/test/resources/META-INF/MANIFEST.MF
URL: 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/resources/META-INF/MANIFEST.MF?rev=602125view=auto
= 
= 
= 
= 
= 
= 
= 
= 
==

--- xmlgraphics/fop/trunk/test/resources/META-INF/MANIFEST.MF (added)
+++ xmlgraphics/fop/trunk/test/resources/META-INF/MANIFEST.MF Fri  
Dec  7 07:36:53 2007

@@ -0,0 +1,5 @@
+Manifest-Version: 1.0
+
+Name: fonts/DejaVuLGCSerif.ttf
+Content-Type: application/x-font
+

Added: xmlgraphics/fop/trunk/test/resources/fonts/ 
DejaVuLGCSerif.LICENSE

URL: 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/resources/fonts/DejaVuLGCSerif.LICENSE?rev=602125view=auto
= 
= 
= 
= 
= 
= 
= 
= 
==
--- xmlgraphics/fop/trunk/test/resources/fonts/ 
DejaVuLGCSerif.LICENSE (added)
+++ xmlgraphics/fop/trunk/test/resources/fonts/ 
DejaVuLGCSerif.LICENSE Fri Dec  7 07:36:53 2007

@@ -0,0 +1,98 @@
+Fonts are (c) Bitstream (see below). DejaVu changes are in public  
domain. Glyphs imported from Arev fonts are (c) Tavmjung Bah (see  
below)

+
+Bitstream Vera Fonts Copyright
+--
+
+Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved.  
Bitstream Vera is

+a trademark of Bitstream, Inc.
+
+Permission is hereby granted, free of charge, to any person  
obtaining a copy

+of the fonts accompanying this license (Fonts) and associated
+documentation files (the Font Software), to reproduce and  
distribute the
+Font Software, including without limitation the rights to use,  
copy, merge,
+publish, distribute, and/or sell copies of the Font Software

Re: FOP and XML Graphics Commons Maven artifacts

[Max Berger]

Cameron,

ok. I've deployed the artifacts from the -jdk1.4 binary release, and
provided instructions at:

http://wiki.apache.org/xmlgraphics/Maven

The directory there is synched with the main maven repository, so the
artifacts should show up within the next 24 hrs.

Letting the maven deploy plugin create the correct directory structure
and needed files is MUCH easier than trying to do this yourself in ant.
I would therefore recommend the use of maven to deploy the maven
artifacts.

For the -jdk1.3 versions, i propose to add -jdk13 to the version, e.g.

groupIdorg.apache.xmlgraphics/groupId
artifactIdxmlgraphics-commons/artifactId
version1.2-jdk13/version

and respective for fop. 

Max

On Don, 2007-12-06 at 10:29 +1100, Cameron McCormack wrote:
 Hi Max.
 
 Max Berger:
  actually, this could be a very fun experiment to see if my new fop
  account is working. It should (theoretically) give me access to the
  people.apache.org server mentioned in the howto. So yes, I am
  volunteering to do it. (And provide a how-to afterwards)
 
 Great!  Since we’re not using maven for building, do you want to have a
 go at modifying fop’s and commons’ maven-artifacts ant build target to
 generate the right files?
 
  There is no particular reason why I mixed the two compiled versions
  other than pure coincidence. Would it be reasonable to upload the 1.4
  artifacts only? Or should the 1.3 jars should also be uploaded (probly
  with something like -1.3 in the name)?
 
 I’m no maven when it comes to maven, so I’m not sure how different Java
 versions are catered for in the repository.  I’ve asked on repository@
 but no reply yet:
 
   http://markmail.org/message/xun2cpohbevhothw
 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: The intermediate format and the plan towards FOP 1.0

[Max Berger]

Jeremias,

Am Dienstag, den 27.11.2007, 11:10 +0100 schrieb Jeremias Maerki:
 it has come to my attention that not everyone seems to be happy that
 some of us are looking into a new design for the intermediate format

exploring a new design is never a bad idea. Indeed, one of the things I
dislike about fop's current design is that a lot of code is duplicated
in the different renderers, and if the intermediate format can solve
this, then it is another reason to use it.

The only thing I am concerned with is fops stability. I use the svn
version for everything, and I am happy as long as trunk compiles, and
translates my documents correctly. So if you do major changes I'd
actually prefer a branch.

One thing that should be considered in trying a new design is that no
functionality should be removed. This was one of the major drawbacks
after the 0.20 - 0.9 rewrite, where at first many things which used to
work before stopped working (and stopped me from using fop 0.9 for a
long time). So IMO merging back the branch should only be done when all
tests run without disabling them.

Just my 2 cts.

Max


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: MathML and fop

[Max Berger]

Dear Juanita,

you mail (this and the last one) should probably go to fop-users instead
of fop-dev. 

The JEuclid FOP plugin requires FOP 0.94. Complete installation
instructions are available in the README.fop file in the JEuclid bundle.
Please send an email to [EMAIL PROTECTED] if you have
further problems with math.

Max Berger

Am Dienstag, den 06.11.2007, 01:42 -0800 schrieb juanita:
 I am using fop 0.93 and I want to be able to display a MathML object 
 in the generated pdf. I read that I can use JEuclid jar for this reason.
 I download jeuclid-fop-3.0.1.jar for this reason and added in the lib
 directory of fop but 
 there is no change.
 Is this version correct or it only aplies for fop 0.94?
 I use a fo.xsl that generates the fo.fo from an html and this fo.fo is then
 generates a pdf.
 the MathMl exists in the html in an  tag and in the fo.xsl  I use the
 fo:external-graphic..
 ...Any clues?
 
 Thank you...
 
 


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Dramatic improvement of PDF text painting quality for SVG

[Max Berger]

Jeremias,


Am Samstag, den 03.11.2007, 12:22 +0100 schrieb Jeremias Maerki:
 Implementation notes:
 - The text painter has a fallback so it can still paint text with SVG
 fonts. Text for which there's no font in FOP's FontInfo object will be
 painted using shapes as before.

Please correct me if I'm wrong:

AFAIK fop does not embed fonts into the document unless explicitly
requested. So with the new auto-detection feature, it will automatically
pick up all fonts on the local system, and provide font-metrics
(FontInfo) for it, but not embed them. If the resulting pdf is moved to
a different machine where the installed font set is different, the
result will look very garbled.

 Feedback welcome. And yes, XSL-FO documents with embedded SVG profit
 from these changes, too. :-)
 Have fun!
 Jeremias Maerki


Max


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Any good documentation on adding extension to FOP

[Max Berger]

Dear Sandeep,

not necessarily documentation, but two working examples are the fop  
plugins from barcode4j and jeuclid:


http://barcode4j.cvs.sourceforge.net/barcode4j/barcode4j/src/fop-trunk/

http://jeuclid.svn.sourceforge.net/viewvc/jeuclid/branches/3.0/ 
jeuclid-fop/


hth

Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 20.09.2007 um 08:24 schrieb vaidyanet:



Hi
Iam just started with FOP and I was tsrying to add a new extension  
to FOP.
Documentation given at the XML graphics is very abstract. Please  
can you

send me some link on where I can get some good documentation to add a
extension to FOP.

Thanks and Regards
Sandeep
--
View this message in context: http://www.nabble.com/Any-good- 
documentation-on-adding-extension-to-FOP-tf4485635.html#a12791591

Sent from the FOP - Dev mailing list archive at Nabble.com.





PGP.sig
Description: Signierter Teil der Nachricht

Re: Fonts page?

[Max Berger]

Andreas,

Looks like there is some text missing here. It should probably be  
something like:


Fonts in well-known paths are automatically detected. The paths for  
Unix-Systems are:

* [ the four bullets]
For Windows Systems these are:
* [add paths for windows]



Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 05.09.2007 um 23:35 schrieb Andreas L Delmelle:



Hi all,

Is there a slight error on our fonts page?

see: http://xmlgraphics.apache.org/fop/0.94/fonts.html#register

What is the function/meaning of the first four bullets?

Have I missed something? Anyone know where these come from?


Cheers

Andreas




PGP.sig
Description: Signierter Teil der Nachricht

Re: Fonts in JAR files

[Max Berger]

Vincent,

Vincent Hennebert schrieb:
 Hi Max,
 
 Some general comments. Basically I agree with Andreas and think this
 would be a good addition.
 
 Your idea of using manifest.xml looks fine. A quick Google search didn't
 give me any result regarding a standard way of bundling fonts with Java
 apps. It looks like you did also search for that before going with the
 manifest.xml approach. Can you just confirm? We wouldn't like to miss
 any pure Java standard way.

I could not find one. Aamof, I could not find any standard way to
include resources in the classpath, and unfortunately the classloader
does not have any notion of directory listing.

I have, however, missed the most obvious format: the META-INF/MANIFEST
file [1]. It can also contain information about the enclosed files and
its attributes, in pairs such as:

Name: somefont.ttf
Content-Type: application/x-font

Also, this format is already implemented [2].

[1] http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
[2] http://java.sun.com/j2se/1.4.2/docs/api/java/util/jar/Manifest.html

I personally prefer the syntax of the manifest.xml file, however for
standards compliance I now think the plain MANIFEST file would be a
better solution.

 Doing the job in XML Graphics Commons would be good, as the font library
 should ultimately rely there. But I'm not sure if this will be easy to
 do without moving the whole font stuff now. If that causes you any
 problem stay in the FOP codebase.

My idea was to have a method simliar to this in commons:

List getResourcesOfMimeType(String mimetype)

where List would be a ListURL


And in FOP:

Font autodetection would then be changed to use URLs instead of Files
(can handle both files found on disk and in Jars, and avoids loading the
whole file content), and then simply adding the resources of the known
font type to the autoconfig list should do the trick.




mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: OpenPGP digital signature

Re: Remove Useless Comments

[Max Berger]

Dear Fop-devs,

as always, I have no say in this, but what I usually do is to use

/** [EMAIL PROTECTED] */

This works really well, if the method inherits from a class / interface
which is also present in the same codebase: Checkstyle is happy, and so
is JavaDoc. Also, JavaDoc gives a warning if a method uses inheritDoc,
but does not implement / override a method (a way of detecting renames
in superclasses)

For some more discussion on this matter, see [1]

[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200503.mbox/[EMAIL 
PROTECTED]

hth

Max

Vincent Hennebert schrieb:
 Hi,
 
 Nothing related with (and against) the original change, but I take this
 one as an opportunity to launch the discussion. I've been having this in
 my head for a while.
 
 -   /** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */
 +/** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */
 
 I'd like to suggest to remove such comments every time there's an
 opportunity. They are useless for javadoc which is able to retrieve the
 comment from the redefined method. They are painful when discovering
 code in Eclipse because when we hover a method call, we get that comment
 instead of the real one, which Eclipse also is able to retrieve.
 
 The only reason I can think of for such a comment is to make checkstyle
 happy. But I don't think this is a solution. Checkstyle should be aware
 that in Java redefined methods inherit their javadoc from the original
 one, and shouldn't complain in this case. So here it's checkstyle that
 is wrong.
 
 Anyway, there are already zillions of checkstyle warnings in the current
 codebase, so I guess we can live with a few more.
 
 
 WDYT?
 Vincent





signature.asc
Description: OpenPGP digital signature

Re: DO NOT REPLY [Bug 42785] - [PATCH] Support baseline-shift for images

[Max Berger]

Andreas,

as said previously: All this is currently future discussion, as the  
last patch is sufficient for now, and I'll probably not revisit this  
for a while. So this mail is just for the archive, for me to come  
back to it later :)


Am 08.07.2007 um 22:45 schrieb Andreas L Delmelle:
Now the second issue (and this requires further investigation  
first, so it will be for post-0.94) is that the image should  
have access to its surrounding context, in particular attributes  
like foreground-color, font-size, etc.. This is of lower priority,  
as these can be set explicitly within MathML context.
How do you mean this precisely? Currently, MathML is used in the  
context of an fo:instream-foreign-object or fo:external-graphic,  
correct?


Correct.

Isn't it already possible then, for the extension object to get a  
reference to its parent or grandparent node in the document and get  
the properties from there?


For instream-foreign-object: correct. For external-object: No, since  
here I am extending the standard Image mechanism (XMLReader, based on  
ImageReader), which IMO does not have a reference to the enclosing  
external-graphic node (it does to FOUserAgent). Although it seems  
like this would already solve the problem, which would make a  
(future) patch to support this very small (Image Readers would then  
have access to their external-object)


Admitted, with the current state of property access --through  
specific accessors on the FONode subclasses-- this could turn out  
to be a bit cumbersome, as you would first have to test whether  
it's a Block, Inline... then explicitly cast it to the right type,  
and use the public accessors to get the desired information (?)
For the information that is available on instream-foreign-object or  
external-graphic itself, like background-color, your root extension  
element could do something like:
((AbstractGraphics) getParent()).getCommonBorderPaddingBackground 
().backgroundColor;


This looks like it would sove the problem. It doesn't look nice, but  
that's ok. Having a mechanism like this and having access to the  
external-object node in the reader could indeed solve this problem.  
When I revisit this i will explorer this mechanism further - as this  
could be done without patching FOP here is the plan:
a) Provide context support for instream objects first, which allows  
testing, and investigating how certain properties are inherited  
within fop.  This will also allow me to see if having access to the  
enclosing element is enough, or if more is needed.
b) When this is ready, provide a patch allowing for image-readers to  
have access to their enclosing as well.

Target for b) is before fop 1.0 comes out :)


Cheers
Andreas


Thanks!

Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name


PGP.sig
Description: Signierter Teil der Nachricht

Re: DO NOT REPLY [Bug 42785] - [PATCH] Support baseline-shift for images

[Max Berger]

Andreas,

thanks! This means I will be able to release a JEuclid plugin for fop  
0.94 which finally renders formulas on the right baseline!


Now the second issue (and this requires further investigation first,  
so it will be for post-0.94) is that the image should have access  
to its surrounding context, in particular attributes like foreground- 
color, font-size, etc.. This is of lower priority, as these can be  
set explicitly within MathML context.


Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 08.07.2007 um 21:49 schrieb [EMAIL PROTECTED]:


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=42785.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42785


[EMAIL PROTECTED] changed:

   What|Removed |Added
-- 
--

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]   
2007-07-08 12:49 ---

Looked OK to me, so patch applied.

see: http://svn.apache.org/viewvc?view=revrev=554423

Thanks for the contribution!

--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi? 
tab=email

--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.




PGP.sig
Description: Signierter Teil der Nachricht

Could someone please clarify the spec for alignment-adjust

[Max Berger]

Dear XSl-Fo experts,

I am now a little confused about the spec on alignment-adjust.  My  
Reference is xsl-fo 1.1 [1]


7.31.22 vertical-align

[...]

percentage
Raise (positive value) or lower (negative value)

[...]


percentage [...]
alignment-adjust=percentage


Which says: Positive numbers raise the box, negative numbers lower  
it, and vertical-align is to be interpreted the same as alignment- 
adjust. HOWEVER


7.14.1 alignment-adjust

[...]

percentage
[...] The offset is opposite to the shift-direction if that value is  
positive and in the shift-direction if that value is negative value).


7.29.7 writing-mode

[...] lr-tb [...]

Typically, this is the writing-mode for normal alphabetic text.



[...] shift-direction to bottom-to-top

Which together results in: a positive value will shift towards bottom  
(lower the box), while a negative value shifts towards top (raise the  
box),which is contradictory to the specification before.


I may have missed something, but I believe this is contradictory.  
Could someone please clarify on this?




[1] http://www.w3.org/TR/xsl/

Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name





PGP.sig
Description: Signierter Teil der Nachricht

Re: FOP 0.94

[Max Berger]

Vincent,

I would love to have Bug 42785 ( patch to support baseline-shift )  
applied before the release, because then I could release a new plugin  
for the new version. I've read your comment, and I will check with  
the spec which options I have to improve the patch, however this will  
take a little while, and I will hopefully be able to do it latest by  
this weekend. What timeline for the release do you have in mind?


Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 05.07.2007 um 09:39 schrieb Vincent Hennebert:


Hi guys,

Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been  
corrected

and many exciting new features added.

Anyone against a new release?

I'd volunteer to deal with all the release process... unless someone
volunteers even more! However, I would gladly accept any help  
regarding

updating the documentation.

WDYT?
Vincent




PGP.sig
Description: Signierter Teil der Nachricht

Re: Character-by-character font selection strategy

[Max Berger]

Dear Fop-Devs,

I've started some work on that in a patch I've submitted a while ago
(which needs cleanup - lots of cleanup)

http://issues.apache.org/bugzilla/show_bug.cgi?id=39422

I've also implemented character-by-character font selection for JEuclid,
which may serve as a reference. Please look at:

http://jeuclid.sourceforge.net/jeuclid-core/xref/net/sourceforge/jeuclid/elements/support/text/StringUtil.html#102
http://jeuclid.sourceforge.net/jeuclid-core/xref/net/sourceforge/jeuclid/elements/support/attributes/MathVariant.html#194

I'll add all three links to the wiki.

Of course the algorithms would have to be modified to work with fop's
font system instead of AWTs.

I'd be very willing to test / enhance a patch, because I really need
this feature (hence my original patch).

One quick wish while you're at it: AFAIK FOP still does not even print a
warning when it replaces a character with the # sign. Please fix this!
(Part of the patch).


mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: OpenPGP digital signature

Extending FOP's image interface

[Max Berger]

Dear Fop-developers,

continuing on the improvements of support for image plugins in Fop
(particularly MathML plugin), there are two more things that need to be
addressed. I am quoting from a previous mail to jeuclid-devel:


Jeremias Maerki schrieb:
 - Context sensitivity: Right now all formulas are rendered using the  
 default fonts, default colors, default size, etc. It would be nice if  
 this information is somehow available from the surrounding fo:block  
 element. (I have no idea where to start looking for this).
 We could capture the CommonFont structure in the bind() method of
 o.a.f.fo.flow.AbstractGraphics (pList.getFontProps()) and pass that
 information to extension implementations that want this information.

This would be great. Unfortunately I have no idea how it would be done
in detail.

 - Baseline offsets
 Should be doable.

I have found a spot where this information would be placeable:
FopImage.ImageInfo. Unfortunately, changing this class could probably
mean that all plugins will have to be recompiled. Here's my idea:

- add a new attribute baselineOffset, default to 0

AbstractGraphics would provide a hook getAdditionalAlignmentAdjust,
and getAlignmentAdjust would use this value;

InstreamForeignObject could then use getAdditionalAlignmentAdjust, to
provide the additional offset needed for inline objects.

So would it be feasible to change ImageInfo, possibly introducing an API
change?

And if so, the current API uses fixed-point sizes only (e.g. all sizes
can only be complete pixels). IMO this should be changed to support
float or double values, as some vector graphics have a higher resolution.


Comments?

mfG

Max Berger
e-mail: [EMAIL PROTECTED]

-- 
OpenPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me and my work please see http://max.berger.name



signature.asc
Description: OpenPGP digital signature

Re: DO NOT REPLY [Bug 42476] - [PATCH] Bugfix for XMLReader: Support for other ImageReaders

[Max Berger]

Vincent,

the problem with the current XML Reader is that it closes the stream  
in all cases. Even though it is the last image reader, it is bad  
because this means there can be no additional ImageReader.


First, let me tell you why I wanted this functionality: I am  
currently working on updating the fop-mathml plugin to work with the  
current version of JEuclid. The work can be found at [1].


Therefore, I would like to add support for two additional Image  
Types: ODF (OpenDocument Formula, basically a .ZIP file with MathML  
in it), and MathML (XML-based).


The plugin registers additional imagereaders, which will run after  
the default image readers.


When the current XMLReader is run with an ODF file, it just spits out  
an error message, but still closes the stream. Any additional image  
reader, such as the ODFReader then has no chance of detecting the  
format, which is bad (and violates the contract stated in the  
interface).


The workaround for this in the SVGReader was the  
UnclosableInputStream (which was declared inline), so what I did was  
externalized it, and also used it in XMLReader. The trick here is to  
use the UncloseableInputStream when passed to external functions  
(such as the SAXReader), and the original input stream when actually  
closing it.


You are absolutely right, there is a .close() now missing when  
XMLReader has recognized the image. But also, ImageReaderFactory is  
missing a .close() if the image is not recognized. I have added this  
and will submit yet another patch.


[1] http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid- 
fop/



Am 26.05.2007 um 17:59 schrieb Vincent Hennebert:


Hi Max,

--- Additional Comments From [EMAIL PROTECTED]  2007-05-23 02:07  
---

Created an attachment (id=20244)
 -- (http://issues.apache.org/bugzilla/attachment.cgi? 
id=20244action=view)

Yet another try


I was about to hit return after having entered the svn commit  
command...

when I decided not to.

This isn't as simple as it seems to be. IIUC, with this change you  
will
end up with InputStreams which will /never/ be closed! I guess this  
will

lead to problems at some time...

In SVGReader, the input stream should be closed after the
createSVGDocument method has been called. Because if this method
terminates successfully, then the document actually is an SVG image  
and

the stream can be closed. Otherwise this method will throw an
IOException, and the following line won't be reached anyway.

In XMLReader we can't really do the same. This class will create a
generic DOM representing the input document, there is no reason why  
that

would fail. But IIUC you want to plug-in your own image reader instead
of relying on XMLReader? Which means that XMLReader shouldn't close  
the

stream. Or do it only if a converter is found for the corresponding
namespace? Probably that.

I'm not a specialist of the image handling area. Does all that make  
any

sense? Thoughts, opinions?


There is still a lot of duplicated functionality in the Image  
Readers, which at

some point should be cleaned up.


You are welcome to work on this if you are willing to. Note that
Jeremias has been having some ideas about refactoring the image
handling, maybe you two will want to synchronize on this.

Thanks,
Vincent



Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name





PGP.sig
Description: Signierter Teil der Nachricht

Re: FOP and XML Graphics Commons Maven artifacts

[Max Berger]

Jeremias,
Jason,

it looks like the only way to properly deploy maven bundles is to  
actually use maven. I have finally managed to install the bundles  
into a local directory for JEuclid, but the same process should apply  
for the apache rsync-repository [1].


The results can be seen at
http://jeuclid.sourceforge.net/m2/

in particular
http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/fop/
and
http://jeuclid.sourceforge.net/m2/org/apache/xmlgraphics/xmlgraphics- 
commons/


you may just be able to take the files from there and copy then to  
the apache rsync-repository.


How this was done? If you use maven, you need to create setting for  
the repository in your .m2/settings.xml and then you can deploy using  
the maven-deploy-plugin. I have documented the whole process in [2].


In the hope that this helps.

[1] http://www.apache.org/dev/repository-faq.html
[2] http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid- 
fop/README


Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 18.05.2007 um 02:28 schrieb Jason Johnston:


Jeremias Maerki wrote:

Dear Maven-users,
I've had enough. I've lost enough time on something I don't need.


I'm sorry for your frustration, and want you to know that I greatly  
appreciate the work you've put in.  I'm sure many others do as  
well. So thank you!



I've prepared Maven bundles as per
http://maven.apache.org/guides/mini/guide-ibiblio-upload.html and  
tried

to submit them. Carlos closes those requests [1][2] with a pointer to
the ASF's repository FAQ. I guess that's fine for projects using  
Maven.

We are not.



At any rate, it looks like the layout of the staging
directory is totally different to what I prepared in the bundle.  
So I'd

have to start all over and have to adjust the build scripts again. I
have no time for that.
You have the bundles. Do with them as you please. If anyone wants to
send patches to Batik, FOP and XML Graphics Commons for producing  
Maven

artifacts, feel welcome to do so.


I'll take a crack at it.  It doesn't look like it's very far off.

--Jason




PGP.sig
Description: Signierter Teil der Nachricht

Adding a cmyk() color function?

[Max Berger]

Hi Developers,

I've just received an email from a person saying that they can't use  
fop because it has problems with CMYK color. One thing they did was  
customize fop and add a cmyk(a,b,c,d) function to describe color.


Even though there is no such thing in the fo specification (there is  
rgb(), system-color(), and icc-color()) i think it would be a good  
idea to have it, as cmyk is a standard color model. It would also  
help testing if FOP can really support different color models. If its  
desirable, then I'll supply a patch implementing cmyk()



Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name





PGP.sig
Description: This is a digitally signed message part

Thoughts about image handling

[Max Berger]

Dear Fop developers,

after a while and some thinking, here is my concept for extensible  
image handlers for fop, or even better for xmlgraphics. If desired, I  
can implement this concept for xmlgraphics / fop with support for  
imageio, jimi and batik.


Image handling is  a three-step process. Step one is detecting the  
file format, step two is loading the image, step three is outputting  
the image into whatever the output renderer is.



Step 1: Detecting the file format.

In most handlers this currently happens by trying to load the files,  
which is very inefficient. Instead, detectors like jmimemagic should  
be used. These should return a mime-type or null if the type can not  
be detected.


To speed up the process, a mime-type may be guessed from the file  
extension, and added as hint


Example interface:

public interface MimeTypeDetector {
  String detectMimeType(URL file, String probableType) throws  
IOException;

}

Step 2: Loading the image.

The image can then be loaded by any image handler that supports this  
type.


Example:

public interface ImageHandler {
  void setImage(URL file) throws IOException;
  // ...
}

Step 3:  Outputting the image.

Generally there are three types of images. Vector images (SVG, MML),  
bitmap images (GIF, BMP, JPEG), and uninterpreted images (EPS)


- Vector images must supply a paint(Graphics g) function
- Bitmap images must supply a method to get the image contents as a  
Raster (similar to java.awt.RenderedImage)
- Bitmap images may supply a method to get the image contents in LZW,  
ZLIB, DCT, format, such as in JPEG or TIFF compression (used in PDF)
- Uninterpreted images just provide a method to get the contents in  
its original format.


Reflection may be used in the renderer to find out the image type,  
rather than checking for the type. Example:


if (image instanceOf VectorImage)  {
  ((VectorImage)image).paint(graphics)
} else if (image instanceOf DCTEncodedImage) {
  addResource(image.getDCTData)
// ...


To support extensibility, a registration mechanism is provided. Here  
is the basic idea:


Java provides standard mechanisms to find all resources with a given  
name in all classpath items. This allows to find all META-INF/ 
MANIFEST.MF files given in all JAR files in the classpath (1). These  
files can be parsed using standard Manifest functionality.


The files contain some attributes that describe classes used. For  
image handlers, this could be a classname and the supported image  
type. It may contain additional attributes, such as supported  
subtypes (e.g. LZW for TIFF). Ideally the exact specification of  
these attributes would be coordinated between fop and foray to  
support reuse.


This information can be parsed once and stored.

This mechanism requires the user to change only the classpath, and  
nothing else.


I have written a short proof-of concept code for the registration,  
available at

  http://max.berger.name/tmp/extTestMain.jar
and
  http://max.berger.name/tmp/extTestProvider.jar

(source is included in the jar files).

To run, try:
  java -cp extTestMain.jar name.berger.max.test.ext.Main
or
 java -cp extTestMain.jar:extTestProvider.jar  
name.berger.max.test.ext.Main




(1) Of course, it doesn't have to be MANIFEST.MF.  For resources such  
as fonts this may well be META-INF/FontDescriptor.xml or something else.




questions? comments?

Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name





PGP.sig
Description: This is a digitally signed message part

Re: DO NOT REPLY [Bug 38946] - [PATCH] for color Handling

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremias,

thank you very much! I'll continue to submit patches whenever I find
something that I need.

Max

[EMAIL PROTECTED] wrote:
 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
 RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38946.
 ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
 INSERTED IN THE BUG DATABASE.
 
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38946
 
 
 [EMAIL PROTECTED] changed:
 
What|Removed |Added
 
  Status|ASSIGNED|RESOLVED
  Resolution||FIXED
 
 
 
 
 --- Additional Comments From [EMAIL PROTECTED]  2006-05-03 07:30 ---
 Patch applied. Thanks a lot. The additional changes to the patch due to the
 changes since patch submission were no problem.
 http://svn.apache.org/viewcvs.cgi?rev=399185view=rev
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEWO2SxVFyWbWycjQRAo6pAJoCIBhrroC/cDwGIXlX/cN15tY5TgCdElqv
NBmSZpwMdi76XR+rmobb5Cg=
=WR8n
-END PGP SIGNATURE-

Re: Question about status of JEuclid and possible inclusion in FOP

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Gennadiy,

thank you for your very extensive answer. At least now I know what the
current status is. So for now I'll use jeuclid externally to convert so
svg and then include that into fop.

Gennadiy Tsarenkov wrote:
 The  reasons  for  rare commits is that on our side there is more then
 one  developer  working  on  the  project.  While  we  do not have any
 feedback,  we  do  not  update  public  repository  and just using our
 private  one.  There is another weak reason, why I cannot made release
 on  sourceforge.net.  I  have  only  CVS  commit rights to the JEuclid
 project and cannot make any releases.

I would like to see your changes in the jeuclid cvs repository. I have
some minor additions to jeuclid where I would like to provide patches for.

Thanks

Max
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEWO/ixVFyWbWycjQRAmzBAJ9Cd7gJYAHnv2yuaUPo9+LWSb6r6QCeJ5/6
0Qw2gAbx37i4V/ulQ0KrmSw=
=KhMX
-END PGP SIGNATURE-

Question about status of JEuclid and possible inclusion in FOP

[Max Berger]

Dear Gennady,
Dear developers,

I've just recently played around with mathml and tried to include  
that in my fop documents. I've found several tools, and among others  
jeuclid. jeuclid is very complete, it is just missing a few adapter  
classes. I've written a small one to convert mml to svg and it works  
just fine.


I've then found out that there was work done merging jeuclid into  
fop / xmlgraphics. What is the current status of this? What are the   
license / technical issues? Is this desired at all?


Here  is what I would like to see:
- include jeuclid in xmlgraphics
- add code to fop to support the inclusion of mml documents as  
external images.

- add code to fop to support mml embedded within fo documents

i would be willing to provide the first two items, if it is legal to  
do so...


Max



PGP.sig
Description: This is a digitally signed message part

Re: Including an sRGB color profile?

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremias,
Fop-dev,

I know I have no vote in this, but I do disagree.

1) I still believe that PDF is a print medium and should therefore
default to CMYK colorspace. If supported correctly by software, the
colors should show up right on the screen.

2) If you want to embedd the sRGB profile, I would recommend using the
profiles found at the International Color Consortium:
http://www.color.org

especially

http://www.color.org/srgbprofiles.html

unfortunately I was unable to find the exact licensing terms.

just my 2 cts.

Max


Jeremias Maerki wrote:
 I'm near the end of my work for basic PDF/A-1b support. PDF/A-1b
 mandates the use of an OutputIntent if uncalibrated color spaces (like
 DeviceRGB) are used. That means that in each PDF which has PDF/A-1b
 enabled an ICC color profile will be embedded and used in the
 OutputIntent object. Since we don't support ICC-based colors, yet, I've
 hard-coded sRGB into PDF/A-1b support (XSL-FO supports sRGB and
 ICC colors, XSL 1.0, 5.9.9). But that means I need to embed the sRGB
 IEC61966-2.1 color profile. The JRE provides such a color profile but
 does this is a weird way: the profile alone is about 140KB. That's why
 I'd like to use the standard sRGB profile from HP. Info on that file:
 
 Obtained from: http://www.srgb.com/usingsrgb.html
 
 The file sRGB Color Space Profile.icm is:
 Copyright (c) 1998 Hewlett-Packard Company
 
 To anyone who acknowledges that the file sRGB Color Space Profile.icm 
 is provided AS IS WITH NO EXPRESS OR IMPLIED WARRANTY:
 permission to use, copy and distribute this file for any purpose is hereby 
 granted without fee, provided that the file is not changed including the HP 
 copyright notice tag, and that the name of Hewlett-Packard Company not be 
 used in advertising or publicity pertaining to distribution of the software 
 without specific, written prior permission.  Hewlett-Packard Company makes 
 no representations about the suitability of this software for any purpose.
 
 I need to get the license approved by the VP legal affairs but I don't
 expect any problems.
 
 Anyone against me including this color profile (3144 bytes, uncompressed)
 in the org.apache.fop.pdf package?
 
 Jeremias Maerki
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFELYebxVFyWbWycjQRApxpAJj4kFIHwFpEnbsoKcGeCOMjsfT7AJ99OHsD
0iDcqGbsIpj5oNN/GAUsXg==
=pX/E
-END PGP SIGNATURE-

Use of colors in fop

[Max Berger]

Dear fop developers,

One of the things I would like to see in fop is proper color management. Of
course, just wanting it is not enough, so I would even create a patch for that
:). I do have some extra time this weekend and next week. To coordinate and get
my idea reviewed here's my plan:

Color is currently handled very inconsistently in many places. In some cases it
is handled as r/g/b values in an int[], in others a class, sometimes with or
without colorspace information. There is duplicated code in many places.

What I would like to do:

- Replace ALL occurences of color values with a common color class. I would
suggest java.awt.Color and java.awt.color.Colorspace. They have proper support.

- Convert that color to the target space no earlier than the output renderer

The default target color space is probably sRBG for most screen display devices.

For PDF it is a little more complicated. Ideally there would be some kind of
PDF-mode option, with possible values of PDF/A-1a, Pdf (print), PDF (screen),
PDF (print B/W), PDF (print Grayscale), ... .For now, using CMYK for PDF should
be sufficient.

Once color is properly used it should be no problem to implement the rgb-cc()
and colorspace() functions.

Quenstions? Comments?

Max Berger

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC
For information about me or my projects please see http://max.berger.name



signature.asc
Description: OpenPGP digital signature