When I download the source for fop 1.0, the ant build shows successful,
but if I try a regular build just to check for errors before running the
ant build I get a bunch of error messages such as "the content of
element type "li" must match..." (on linkmap.xml). Is this normal or am
I missing somet
While it may be possible in Java as it was in old languages like C to
write an entire program on one line, it is more readable to break it
out.
I agree there shouldn't be an arbitrary limit such as no line longer
than 100 or 80 or 200 characters. Sometimes it may make sense to string
more than tha
I see there's still a classpath statement in the 1.0 Manifest.mf file.
Is this necessary? Could this be removed in the next version, and
document a classpath parameter to pass for manually executing? I run
this with embedded code from an app which already has a classpath, so I
have to recompile a
On Tue, Aug 10, 2010 at 9:09 PM, Jeremias Maerki wrote:
> fine-tuning CheckStyle is probably a good thing.
oh, i completely agree on that, and i'm sure we will find that opportunity
as time permits, and when it does, i will happily contribute a number of
comments for consideration; but that conv
https://issues.apache.org/bugzilla/show_bug.cgi?id=49735
Summary: Only one resource dictionary for the whole document
causes trouble splitting a PDF
Product: Fop
Version: 1.0
Platform: All
OS/Version: All
Status: NE
I believe English has more words than any other language, which is why
they say it's the easiest language to learn and the hardest language to
master.
I would think warnings like calls to deprecated methods should be fixed
asap.
Other warnings like dead code and unused variables I would guess were
Well, I'm not a native English-speaker, so maybe my choice of the word
"rant" was too much. Anyway, Glenn, we're not too far apart. I try to
remove warnings whenever I change a class, i.e. gradual improvement as
time allows. Sometimes CheckStyle would bark at something that I didn't
consider a prob
my apologies if my statement appeared to be a "rant", as it was not intended
as such;
perhaps my emphasis was an exaggeration, but if one goes through the trouble
to add build rules for style checking, bug finding, and code quality
reporting, then it does appear odd to ignore them, which was my re
If you prefer I can send coding issues to fop-users. I'm aware of the
auto detect. I'm just not aware of how it works, if it will find the
file I'm specifically trying to reference or if it might use a search
path which would refer to a different file. I was trying to pass it a
specific path to
I did figure out why I kept getting build successful without getting a
new fop.jar. Apparently the ant script was telling it not to update the
jar when it already exists. I worked around it by adding a delete
method in the script before the part where it gets initially created.
-Original Me
I kind of agree with Glenn that we have a de-facto agreement on the
Checkstyle rules. We've adjusted them in the past and there's no reason
why we can't change it in the future. If Glenn's patch gets the issue
count down significantly so we can start to enforce the rules, then I'm
fine with it. But
Hi Jeremias,
Thanks for looking into this. I am finding that the colours in the
PTOCA and the F11 IOCA appear identical in the viewers that I have
tried too.
I printed your example and the the background colour #FFCC00 appears
identical. I tried this shade with my rounded corners with identical
Vincent,
I disagree with your proposed delay. First, there is an established
consensus on the rules, namely those that are in the existing
checkstyle-5.0.xml file. The reason they are the current consensus is that
they are there in the trunk, and nobody has objected to them. I do not care
to objec
https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
--- Comment #5 from Vincent Hennebert 2010-08-10
06:34:29 EDT ---
Hi Glenn,
Thanks for your patch. However, as I said we need to agree on a project-wide
Checkstyle configuration first. Before enforcing a no-warning policy it is
necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=49727
Ruud changed:
What|Removed |Added
OS/Version||Windows 7
--
Configure bugmail: https://is
Certainly not from me. So far I was always asked by my clients to add
all new features to the Renderer, too. But instead of using the
PDFRenderer (for example) directly, one can always use the IFRenderer
with PDFDocumentHandler as its backend which should make the transition
easier.
Maybe it's a b
Eric,
once again, a post that should have gone to fop-users.
Please see: http://xmlgraphics.apache.org/fop/latest/fonts.html#autodetect
It will tell you how to create a JAR with fonts that FOP will
automatically detect. No Java code necessary.
On 06.08.2010 17:58:55 Eric Douglas wrote:
> I create
I don't use the Ant script to compile FOP inside Eclipse. I only use
"ant resourcegen" on the command-line for code generation. From there I
set up a normal Eclipse Java project.
And besides, IMO the Maven Eclipse plugin is trouble. I've uninstalled
it long ago and I'm using "mvn eclipse:eclipse"
Hi Peter
I did some experiments mixing PTOCA-built backgrounds with GOCA-built
rectangles and SVG converted to bitmaps (see attached FO). When I look
into the generated file, all three elements use the same RGB values
(#FFCC00).
What we need to keep in mind here is that all colors are interpreted
a.k.a. CTR (commit then review)
On Tue, Aug 10, 2010 at 1:54 PM, Glenn Adams wrote:
> Regarding the patch I just posted, I would recommend applying CBR policy to
> get it into the trunk ASAP before other changes are committed. Of course,
> the present committers will decide the appropriate proce
20 matches
Mail list logo
