Matthias,
I put my changes here:
http://people.apache.org/~jeremias/fop/Experiment%20LZW%20Embedding.zip
Please note that testing is not enough in this case. As soon as you
run into a multi-strip TIFF, the whole thing currently fails. As
mentioned in my post, solving this might require
I also find the HiddenField check annoying. So I removed the two rules
that were talked about and removed the Checkstyle 3.5 configuration. I
haven't deleted the v4 configuration due to Vincent's comment (I've also
not upgraded, yet), so I let it stay for the moment. We can always
remove it later.
Prakash, I think you can safely remove the mirroring in the CTM. It's
definitely not the right thing to do for rl-tb. However, please check
the test cases in test/layoutengine/standard-testcases which probably
contain checks for the CTM. These will need to be changed.
Please try to contact the
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
Hi Vincent,
good catch! Your observation is correct. That value must not be a direct
object.
I guess the reason Acrobat doesn't complain is that a PDF parser usually
doesn't really care whether a PDF object is direct or indirect as it is
handled transparently. Still, another implementation might
I've just stumbled over PNGRenderer_onthefly again. There is PNGRenderer
and PNGRenderer_onthefly. PNGRenderer_onthefly is not really offering
anything that PNGRenderer doesn't, so I'd like to remove it. It's not
hooked into the dynamic lookup so has to be instantiated in client code
to use.
Is
Max, I don't think that Checkstyle is the right tool to avoid the
self-assignment problem. Tools like FindBugs are much better in that
regard since they actually check the semantics of the assignment rather
than just complaining that a field and a parameter are named the same.
On 01.10.2009
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
Should the rule be disabled because of that? Having proper javadoc on at
least public methods is very important. OTOH, this is actually not
something Checkstyle can verify. How many methods in the code base have
totally useless comments that
Hi Max,
The same variable name should ALWAYS refer to the same variable / value.
I think, I can second this.
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.
In my attachment Tag.java,
Hi Vincent,
in Intellij Idea, I have also annoying yellow marks in my code. So if
the common policy is to not violate any warning, I won't do that.
Best Regards
Alex
-
e-mail: alexanderk...@gmx.net
web:www.alexanderkiel.net
On Thu, 2009-10-01 at 10:41 +0100, Vincent Hennebert wrote:
Hi Max,
Thanks for your explanation.
Max Berger wrote:
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
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #22 from Vincent Hennebert vhenneb...@gmail.com 2009-10-01
04:02:45 PDT ---
(In reply to comment #21)
I've just noticed that the structure tree stored in the IF XML is not
re-parsed. Running FOP with the IF as input (-afin)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #23 from Vincent Hennebert vhenneb...@gmail.com 2009-10-01
04:05:43 PDT ---
The number tree corresponding to the ParentTree entry in the StructTreeRoot
object is invalid, as the values are directly stored in the array instead
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #24 from Vincent Hennebert vhenneb...@gmail.com 2009-10-01
04:10:58 PDT ---
Are images supposed to work? I've tested a simple document that contains an
fo:external-graphic referring to a PNG image. The alt-text isn't read aloud
Hi,
do we use code, tt or {...@code}? I found all three version. Is there a
Checkstyle for that?
Do we introduce a newline between the Javadoc body and the @param,
@return or @throws clause? Again I see both:
/**
* create the /Font object
*
* @param fontname the internal name
Hi Alexander,
Alexander Kiel wrote:
Hi,
do we use code, tt or {...@code}? I found all three version. Is there a
Checkstyle for that?
Use {...@code}. HTML tags should be avoided as much as possible.
Do we introduce a newline between the Javadoc body and the @param,
@return or @throws
On 01.10.2009 15:08:55 Vincent Hennebert wrote:
Hi Alexander,
Alexander Kiel wrote:
Hi,
do we use code, tt or {...@code}? I found all three version. Is there a
Checkstyle for that?
Use {...@code}. HTML tags should be avoided as much as possible.
Do we introduce a newline
Hi Jeremias,
there is a JavadocStyleCheck. I have it includes in my
checkstyle-5.0.xml for testing. I use the standard settings. It tests
for empty JavaDoc and missing points in the first line.
I didn't found anything which checks for {...@code} instead of tt and
code. Can we add the use of
Hi Jeremias,
Jeremias Maerki wrote:
On 01.10.2009 15:08:55 Vincent Hennebert wrote:
Hi Alexander,
Alexander Kiel wrote:
Hi,
do we use code, tt or {...@code}? I found all three version. Is there a
Checkstyle for that?
Use {...@code}. HTML tags should be avoided as much as possible.
Do
Hi,
Am I right in thinking that images are always rendered into PDF as Image
XObjects, and never as inline images (section 4.8.6 of the PDF
Reference, Third Edition)?
Thanks,
Vincent
On 01.10.2009 15:55:57 Alexander Kiel wrote:
Hi Jeremias,
there is a JavadocStyleCheck. I have it includes in my
checkstyle-5.0.xml for testing. I use the standard settings. It tests
for empty JavaDoc and missing points in the first line.
Yes, but it can't check for that mandatory line
That's right. We don't currently have any infrastructure to give hints
to FOP that an image is one used once and could therefore be inlined.
Still, inlining the images doesn't make much sense in PDF, IMO. Such
infrastructure could provide optimization potential for PS and AFP
output. PDF wouldn't
Hi Jeremias,
there is a JavadocStyleCheck. I have it includes in my
checkstyle-5.0.xml for testing. I use the standard settings. It tests
for empty JavaDoc and missing points in the first line.
Yes, but it can't check for that mandatory line between the body and the
parameters, right?
Hi,
I want to include X and Y coordinates to the afp:include-page-overlay
definition, something like below
afp:include-page-overlay id=IPO001 name=O1tcgas1 *x=300
y=500*/
in PageObject.java, the following method will be used when there is an
overlay referenced in a FO document.
On 01.10.2009 16:44:13 Alexander Kiel wrote:
Hi Jeremias,
there is a JavadocStyleCheck. I have it includes in my
checkstyle-5.0.xml for testing. I use the standard settings. It tests
for empty JavaDoc and missing points in the first line.
Yes, but it can't check for that mandatory
Venkat,
first of all you probably need to subclass AFPPageSetupElement to add
support for carrying the offset coordinates. AFPElementMapping would
then also need to be changed. Then you'd need to move on to
AFPDocumentHandler.handleExtensionObject where the extension is
converted into calls into
Hi Jeremias,
While researching I found that I seem to have used @code accidentally in
some places but with the actual intention of using @link (see
IFDocumentHandler, for example). What a mess. :-( I'll fix that.
I've already fixed the obvious mistakes.
There are only 23 other
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #25 from benoit.wi...@gmail.com 2009-10-01 08:19:20 PDT ---
table-and-caption and table-caption are not supported by FOP but they do not
crash the engine
On the Accessibility branch, a file with a table-and-caption /
On 01.10.2009 17:09:48 Alexander Kiel wrote:
Hi Jeremias,
While researching I found that I seem to have used @code accidentally in
some places but with the actual intention of using @link (see
IFDocumentHandler, for example). What a mess. :-( I'll fix that.
I've already fixed
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #26 from benoit.wi...@gmail.com 2009-10-01 09:03:41 PDT ---
the NPE is at the line
structElemType.put(ptr, structElem.get(S).toString());
structElem.get(S) returns null
it seems to be caused by
https://issues.apache.org/bugzilla/show_bug.cgi?id=47927
Summary: Automatic text overprint patch
Product: Fop
Version: 1.0dev
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #27 from Jeremias Maerki jerem...@apache.org 2009-10-01 09:13:20
PDT ---
(In reply to comment #24)
Are images supposed to work? I've tested a simple document that contains an
fo:external-graphic referring to a PNG image. The
https://issues.apache.org/bugzilla/show_bug.cgi?id=46705
--- Comment #28 from Vincent Hennebert vhenneb...@gmail.com 2009-10-01
09:34:41 PDT ---
(In reply to comment #27)
(In reply to comment #24)
Are images supposed to work? I've tested a simple document that contains an
Hi,
I know my goal is to implement basic OpenType support for FOP. But from
font subsetting/embedding my eyes touched the actual PDF output
routines.
I think, that this module needs refactoring. If you have a look at the
PDFWritable interface, there is a really ugly method. The method
Hi Alexander,
I feel your pain bro [1] - I recommend you have a good read through the
mail archives. This is unfortunately a very familiar story when trying
to add new features to the FOP code base. Fonts are probably the one
area that is most in need of refactoring. I get a reassuring
35 matches
Mail list logo
