Vincent Hennebert wrote:
Hi all,
I'd like to have the opinion from the team about how I should proceed.
I'm currently at a point where I think I know enough, both from
theoretical and code points of vue, to start the implementation of
floats. By mimicing the handling of footnotes, I think I
Jeremias Maerki wrote:
Subject says it all. I think it's time. They work pretty well and have
grown beyond sandbox state. I'm sure there maybe a few nits here and
there, but the same applies to the other renderers.
+1 from me.
+1 from me too. My thanks to all those who improved the AFP and
Jeremias Maerki wrote:
Andreas, what about you? Could you make it to the Cocoon GetTogether?
One or two days of Hackathon (discussions, hacking, fun). Anyone else?
Jörg, Chris, Finn, Peter, Vincent maybe?
Sorry I can't make it either!
Chris
[EMAIL PROTECTED] wrote:
Hi Jeremias,
snip/
Well I figure that the thread will just be blocked in queue.remove
most of the time unless it has something to do. I don't think there
is much overhead for a thread in the types of systems we are targeting
(i.e. not small constrained
[EMAIL PROTECTED] wrote:
[javac] /x1/gump/public/workspace/xml-fop-
maintenance/build/src/org/apache/fop/svg/PDFTranscoder.java:233:
getViewTransform(java.lang.String,org.w3c.dom.Element,float,float,org.apache.
batik.bridge.BridgeContext) in org.apache.batik.bridge.ViewBox cannot be
Andreas L Delmelle wrote:
On Aug 24, 2006, at 19:45, Andreas L Delmelle wrote:
On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
Hi Chris,
snip /
Well I'm not sure if its one of your recent changes thats to blame,
but I've just noticed that simple tables (test file attached) appear
[EMAIL PROTECTED] wrote:
snip/
}
-// then try any family with orig weight
+
+// try the same font-family and weight with default style
+if (f == null) {
+key = createFontKey(family, normal, weight);
+
Bertrand Delacretaz wrote:
Hi FOPpers,
I'm going to commit code from Vincent's patch [1] probably later
today, to the foray-font branch, as we're going to work on it together
in the next few days.
As it's a really big patch, I assume it's ok to do that without
waiting for other committers to
Andrejus Chaliapinas wrote:
Normally, I just construct the FO part in the test case and then run the
thing once so I get the current area tree XML. I obviously get an error
if I have no checks, because we don't want any test cases without checks.
When I have a first area tree XML I create the
woolly wrote:
snip/
Fop reads in the fo source and creates an area tree from it.
Whilst the area tree is being created,
PageNumberCitationLayoutManager.getPageNumberCitationInlineArea(LayoutManager
parentLM) is used to generate InlineAreas. In this method, if the page
number is known, a
Vincent Hennebert wrote:
Hi Bradley,
Bradley Harrington a écrit :
Hello,
I don't know if this is a known problem or not, however the
display-align attribute always puts the text at the top of the cell for
me. I have tried this with both trunk and 0.92 beta. It does work with
other XSL
Bedin, Guilherme (RD Brazil) wrote:
Hi,
I have been developing modifications on fop-0.25 to suite our need
for a couple of years. And now we are trying to move on and start to use
fop-0.92.
To start, I am trying to implement fo:flow-map support on the 0.92 code
(I am using the code from
Manuel Mall wrote:
On Tuesday 19 December 2006 23:55, Manuel Mall wrote:
snip/
Its looking OK so far and most of the layout engine tests pass.
Just discovered the first instance of an existing testcase which gives a
different result. Under UAX#14 the following text (Note this is plain
Vincent Hennebert wrote:
Guys,
If I'm correct the StrokeSVGText is no longer available in the new
codebase? Can I remove the paragraph [1] about it in the doc?
Hi Vincent,
I believe you are correct. The code now makes the best decision about
whether or not the text should be stroked in
Vincent Hennebert wrote:
(As you can see I'm currently checking the consistency of the
documentation before releasing)
On the Upgrading page [1] it is stated that The new FOP extension for
Barcode4J will be available in January 2006. By quickly looking at the
Barcode4J I haven't found any
Simon Pepping wrote:
I have prepared the release files for the FOP 0.93 release. They were
created from the tag
https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_93. You
can find them at http://people.apache.org/~spepping/. They are signed
with the same PGP key as this message. You can
Jess Holle wrote:
I had thought/hoped 0.93 supported table-layout=auto as I know there
was a GSOC project along these lines, yet I note that the compliance
table does not indicate such support.
Is the table in error? If not, how far off is such support?
No, the compliance page is correct.
Jeremias Maerki wrote:
Do I have a slightly distorted perception or do we currently see an
increase in activity, even patches, following the 0.93 release?
Hi Jeremias,
yes I think there has been a increase in both user and development
activity in the few weeks since the New Year. Maybe as a
Andrejus Chaliapinas wrote:
Hi,
I've tried to use this table cell constraint with fop-trunk:
vertical-align is a shorthand for several FO properties including
display-align. I don't believe display-align is properly assigned when
using vertical-align. Try using display-align directly
Jim Tivy wrote:
Hi Folks
I am new to this community. Thanks to all the FOP contributors to getting
this out.
We are trying to deploy a formatting solution to a customer. One reason we
chose .93 was because it would allow us to define an even page with zero
renderable space - done by setting
Vincent Hennebert wrote:
Guys,
It may be worth clarifying which version of XSL-FO we officially
support, now that 1.1 has reached the status of a recommendation. I
guess we can now take it as a reference, since it clears some
uncertainties of the 1.0 version. I've just noticed that I'm myself
[EMAIL PROTECTED] wrote:
snip/
CSS doesn't have the last word here. See the definition for the 'left' property
(XSL-FO 1.1 - §7.6.5) all the way at the bottom. In XSL, these are interpreted
relative to the prevailing coördinate system. Not to the containing block as in
CSS, but to the
Arun Kumar wrote:
I am trying to do the following
By hijacking Vincent's Thread, you have posted your question about FOP
to the XSL Editors Please don't hijack threads and be careful who
you post to!
fo:table-cell
border-left-color=green border-left-style=dotted
Martin Voelkle wrote:
Hello
We needed font-stretch for PDF output at work, so I implemented it.
Good news :)
I got a nice stretch with the following example:
http://xep.xattic.com/xep/testsuite/features/stretch.fo
It is quite incomplete, but I hope that others will want to hack it a bit.
[EMAIL PROTECTED] wrote:
Hi,
We are using FOP-0.20.3 loaded into Oracle 9i database (Oracle9i
Enterprise Edition Release 9.2.0.7.0) in order to dynamically generate
PDF documents using stored in the database
XML and XSL-FO stylesheets.
Firstly, I should mention that this is the wrong
Vincent Hennebert wrote:
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.
Including collapsing border model ;)
Anyone against a new release?
No, I
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2007-07-10 09:34 ---
Apologies, but bugs in FOP 0.20.5 will no longer be fixed.
Please try FOP 0.93 or the Trunk, and see if the problem persists there.
Hi Andreas,
I notice you closing a few 0.20.5 bugs and
Andreas L Delmelle wrote:
snip/
As far as I can judge, /if/ the names of embedded fonts forcibly need
to be altered because they would be overridden by local fonts in the
PDF viewer, then it could turn out to be pretty simple --for someone
who knows what he's doing :/
Leave the
J.Pietschmann wrote:
Vincent Hennebert wrote:
Shall we launch a poll on fop-user about abandoning support for 1.4 and
require 1.5 as a minimum? :-]
A poll: maybe. Abandoning 1.3: Not yet.
Did you mean 1.4 here? I thought we had all agreed to drop support for
1.3 now? I have long argued
Jeremias Maerki wrote:
On 18.07.2007 18:00:57 Andreas L Delmelle wrote:
On Jul 18, 2007, at 17:44, Manuel Mall wrote:
Hi Manuel
snip /
This proposed patch seems to cause a side-effect I would like a
clarification on. The following fo snippet
fo:block keep-together=alwayssome long
Fellow Devs,
I have been doing a little bit of testing with the current Trunk code
and observed that I can generate an OutOfMemoryError simply by
submitting the same 2 page document to FOP to render to Postscript over
and over again. After just 2,900 renderings FOP dies with
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:15, Andreas L Delmelle wrote:
FWIW, I did a quick while(true){...} test with a modified version of
our ExampleFO2PDF. With basic documents, I can't seem to reproduce it.
The last cycle, I stopped at 1 renderings, but I'm pretty sure it
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always post
it, but I'll try to see if I can reproduce with a simple FO without
special features. If I don't succeed, I might ask
Chris Bowditch wrote:
Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always
post it, but I'll try to see if I can reproduce with a simple FO
without special features. If I
Jeremias Maerki wrote:
On 20.07.2007 11:52:15 Andreas L Delmelle wrote:
snip/
In addition to that there was a bug in FixedLength.equals() that made
the caching effect-less:
http://svn.apache.org/viewvc?view=revrev=557934
That was the most likely cause. The equals() method returning
The Web Maestro wrote:
On 7/29/07, Andreas L Delmelle [EMAIL PROTECTED] wrote:
On Jul 27, 2007, at 18:36, Andreas L Delmelle wrote:
it would be good to refactor
the website before the release and, in particular, remove the 0.20.5
tab.
This could maybe still be done before the release, but
Vincent Hennebert wrote:
Hi Adrian,
snip/
Well it seems that target-resolution would also be fine for AFP.
Actually, by looking at the doc it seems that this parameter actually
has 2 different purposes: the resolution of the output when FOP produces
bitmap images, and the resolution of
Vincent Hennebert wrote:
Hi Chris,
Hmmm, I’m perhaps making a confusion here. I thought target-resolution
did also apply to the whole images generated by the renderer; i.e., for
the TIFF renderer, the resolution of the image representing the whole
document, and not only images inside it.
Vincent Hennebert wrote:
Hi,
I’m suddenly all confused about the supposedly expected behaviour of
breaks. Please have a look at the attached FO file and its PDF result.
We get 2 pages. The break-before on the outer block and the inner block
are “merged” into just one... Why?
Well I can't
Vincent Hennebert wrote:
Hi all,
There’s something quite strange in the layout code that I suspect comes
from the pre-Knuth era.
Yes I think you are right.
AbstractLM defines a reset method that among other things calls
resetPosition on children LMs. If you search for references to this
Simon Pepping wrote:
Hi,
I just created the branch Temp_Interleaved_Page_Line_Breaking and
committed code to it. The branch contains a file BRANCH, which states
the purpose of the branch as follows:
This is branch Temp_Interleaved_Page_Line_Breaking. It holds the
development of interleaved
Andreas L Delmelle wrote:
snip/
Hi Andreas,
That is not DISagreeing with me, I think (almost on the contrary). I
did not mean total-fit in the sense of the implementation of the
algorithm, but total-fit as to the end-result: as such, a total-fit
result may precisely require a breaking-up
Jeremias Maerki wrote:
Ok, I agree that renderer-resolution is a good name if we need a
per-renderer setting for the resolution. But applying Adrian's patch
#43041 would leave the codebase in a strange situation where you have to
configure the AFP renderer through the renderer setting and the
[EMAIL PROTECTED] wrote:
Author: jeremias
Date: Tue Oct 16 08:12:45 2007
New Revision: 585167
URL: http://svn.apache.org/viewvc?rev=585167view=rev
Log:
Bugfix: If auto-detection is enabled, auto-detection didn't get done starting
with the second rendering run in the same JVM. Static variables
Pascal Sancho wrote:
Hi Vincent,
some weeks ago, I've checked some old bugs.
Attached the list of these bugs and what are fixed in latest trunk.
Since I'm neither reporter, nor fop dev, I didn't close those bugs.
Don't know the best way to help...
Hi Pascal,
you dont need to be a
Fellow Committers,
As you all know Max Berger is heavily involved with the JEuclid MathML
project. However, he has also been active on fop-dev. A quick search of
the archives shows his first post to fop-dev was over 12 months ago [1]
More importantly Max has submitted several high quality
Fellow FOP Devs,
periodically I run a test suite of documents against FOP Trunk to ensure
no new major issues have occurred since I last took a build of Trunk to
use in my application. Part of the test suite involves running a set of
a few documents several thousand times through FOP. After
Chris Bowditch wrote:
snip/
Does anyone know why CacheEntry.ref can be null in this context and why
this only happens after a few thousand documents have been run through?
Previous documents all have the same property values. Perhaps the GC has
collected the object referenced by ref?
A lot
Andreas L Delmelle wrote:
snip/
A lot of the code that accesses the ref member variable has checks
for null and since it is a WeakReference I assume the cause of this
error is the Garbage Collector removing the reference. Adding a check
for null in the rehash method seems to avoid the
Andreas L Delmelle wrote:
On Nov 12, 2007, at 19:10, Andreas L Delmelle wrote:
Hi Chris
On Nov 12, 2007, at 18:29, Chris Bowditch wrote:
snip /
Thanks for the prompt reply! I've now committed the check for null
in the rehash method.
Good! Just checked the code more closely, and I
Andreas L Delmelle wrote:
Hi Andreas,
snip/
Just looked closer, and I may have found a slightly better way of
dealing with it.
Since the cause of the problem is CacheCleaners interfering with
rehash(), maybe the below patch is a better approach.
Once rehash() has been entered, and has
Andreas L Delmelle wrote:
Hi Andreas,
A splendid idea!
I already thought my approach to be lacking somewhere, although it was
too late last night to see where exactly. First off, the flag should,
of course be declared 'volatile'. If not, then there is no guarantee a
thread will see the
Jeremias Maerki wrote:
The attached patch should fix the memory leak Chris described (in one of
my runs the number of CacheEntry instances after a full GC went down
from 10575 (169KB, before the change) to 386 (6KB, after the change).
I've run various documents through the multi-threading
Andreas L Delmelle wrote:
On Nov 14, 2007, at 21:38, Jeremias Maerki wrote:
Hi Jeremias, Chris,
jm-PropertyCache-MemLeak.diff.txt
My proposal, incorporating the changes in Jeremias' diff, below.
Thanks for the diff. Unfortunately I have been unsuccessful in applying
it after several
Andreas L Delmelle wrote:
On Nov 15, 2007, at 16:30, Chris Bowditch wrote:
Thanks for the diff. Unfortunately I have been unsuccessful in
applying it after several attempts. First I tried using Tortoise SVN
client, then I downloaded GNUWin32 Patch and that fails to apply all
but hunk 7
Avalon wrote:
Hi,
can anyone give a comment about the status of bug 38880?
(http://issues.apache.org/bugzilla/show_bug.cgi?id=38880)
It has been reported long before and when working with borders on inline
element there seems to be no workaround than disabling hyphenation,
which is no option
Andreas L Delmelle wrote:
Hi Andreas,
On Nov 16, 2007, at 17:38, Chris Bowditch wrote:
snip /
Both the 'theoretical limit' issue and the 'too many threads'
should be resolved.
No OOM Error yet, but I'm sure it can't be far away. I just wanted to
update you before I go offline
Chris Bowditch wrote:
snip/
Tested it here, and I don't see any immediate leakage anymore.
One 71-page document, and with -Xmx256M, the heap never exceeded
+/-85M. Each document rendered consistently within 3-4s (ran up to
1000 subsequent renderings).
Well memory seems okay
Jeremias Maerki wrote:
snip/
That is a simplistic way of looking at at but at least its objective
rather than subjective.
Uhm, with these things you can always manipulate the plus/minus items so
that the calculation results in the desired value. I've seen the bad results
of such an
Andreas L Delmelle wrote:
On Nov 20, 2007, at 17:53, Chris Bowditch wrote:
Hi Chris
Hi Andreas,
Made yet another attempt to simplify/correct the design a bit (and
hopefully fix the leak as well).
Thanks for taking the time to revisit this problem :)
Although I noticed
Andreas L Delmelle wrote:
snip/
Sorry, hadn't updated for over a week... :/
No problem. It was easy enough to revert to the previous revision.
snip/
Ouch! I wasn't using the right expression to map from the stale entry's
hashCode to the corresponding bucket index.
Fixed in the diff in
Jeremias Maerki wrote:
I've been playing with the idea for some time and the time has come to
bring this up. I would like to write an FO extension which allows to
insert a multi-page document into an FO document, so each page produces
a new page of exactly the same dimensions as the bitmap
Andreas L Delmelle wrote:
snip/
Those components/resources that apply to all types of renderers, can be
handled in AbstractRenderer.
AbstractRenderer could provide a generic createResource() method, which
can be overridden or re-implemented in the specific renderer types to
handle the
Vincent Hennebert wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a vote for releasing version 0.95beta of Apache FOP. The
candidate distribution files were created from the following tag:
https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_95beta/
(rev. 638320). They may
Jeremias Maerki wrote:
snip/
FOP community, if you think I drifted out of line lately, please set me
straight. Vincent's voice is only one. I know this scene here is ugly
and nobody wants to waste his precious free time on participating in
fights between two people. The fight also doesn't
Vincent Hennebert wrote:
Hi Guys,
I would like to raise this topic again: what about switching to Java 1.5
as a minimum requirement?
Hi Vincent,
I'm happy to allow the use of generics in trunk code if retroweaver is
used to maintain Java 1.4 support. I don't think the time is right to
Max Berger wrote:
Hi Max,
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
Max Berger wrote:
Hi Max,
snip/
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
Andreas Delmelle wrote:
snip/
In the meantime, I made this change locally, but stumbled on the fact that we
do not have an event defined for non-applicable properties.
Now I'm wondering whether we should warn about those at all. According to the
XSL-FO Recommendation, any property may be
Amarjeet Yadav wrote:
Hi,
From a pdf generated with FOP i cannot copy paste to a word document,
i use the 0.20.5 version of FOP.
Please help me.
First of all this is the wrong forum to ask questions about FOP. In
future please direct questions to [EMAIL PROTECTED]
v0.20.5 is
Chris Bowditch wrote:
snip/
I understand that is what happens behind the scenes, but IMO it is
meaningless to the average user. I think it makes sense to change the
message to:
table too wide for available page width
or similar. Then the user knows what they have to adjust in their FO
Jeremias Maerki wrote:
snip/
How about:
An fo:table is wider than the available room in
inline-progression-dimension. Adjusting end-indent based on
overconstrained geometry rules (XSL 1.1, ch. 5.3.4)
I'd like to have the hint about overconstrained geometry in there
because this condition is
bonekrusher wrote:
Hi,
Thanks Peter.
C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml
This file is missing.
That file is created by the build process. I think Peter was talking
about how the build process references the file internally.
snip/
Chris
Dave of Siemens wrote:
This is my first post. We've been using Apache FOP quite successfully for
the past year or so, converting XML for technical manuals to PDF. The one
feature that we're anxious to see is indexing support (XSL-FO 1.1, 6.10).
Does anyone know if this is being worked on?
Vincent Hennebert wrote:
Guys,
What do you think of removing entries in the FAQ section that are
specific to 0.20.5 and earlier versions? This would make it shorter, so
less likely to scare people away, and in the same time easier for them
to find the answer to their question. Plus it would
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
Adrian Cumiskey wrote:
Jeremias,
Adrian,
Jeremias Maerki wrote:
I'm sure if such a person existed and they wrote their own FOP
plug-in they could very easily fix a very small compatibility issue
such as this.
Again: it's not the fix that is the problem. It is about
Adrian Cumiskey wrote:
Hi Adrian,
Hi Andreas,
2008/11/25 Andreas Delmelle [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Adrian, just a small FWIW: Chris has drawn the right conclusion, I
think. No need to take any of the questions/remarks personal (even
though I understand this is
Georg Datterl wrote:
Hi Vincent,
At that point, you may want to create a bug report on FOP's bugzilla
and attach a patch with your current modifications, so that we can
have a look at it and provide you with early guidance.
https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop
Hi Jeremias,
Am I right in thinking supporting fixed width spaces in AFP is the same
as bug 46278? If so then you've made me a happy man!
Thanks,
Chris
Original Message
Subject: svn commit: r734105 - in
Jeremias Maerki wrote:
Hi Jeremias,
snip/
Embedding the fonts is easy enough: you can just copy the files as new
objects into the file-level resource group. IBM's AFP Workbench will
still ignore the embedded fonts and replace them for system fonts but
that's pretty irrelevant. Pixel-oriented
Vincent Hennebert wrote:
Hi Vincent,
Jeremias Maerki wrote:
On 10.02.2009 13:22:01 Vincent Hennebert wrote:
Hi Jeremias,
A few suggestions:
snip/
section id=introduction
titleIntroduction/title
p
-The intermediate format (IF) is a proprietary XML format that
Jeremias Maerki wrote:
Hi Jeremias,
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
Jeremias Maerki wrote:
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.
Good work. +1
Chris
Andreas Delmelle wrote:
Hi Simon and Andreas,
On 07 May 2009, at 21:15, Simon Pepping wrote:
On Thu, May 07, 2009 at 03:08:30PM -, cbowdi...@apache.org wrote:
Author: cbowditch
Date: Thu May 7 15:08:30 2009
New Revision: 772672
URL: http://svn.apache.org/viewvc?rev=772672view=rev
Vincent Hennebert wrote:
Hi All,
Hi Vincent,
While I am making rather good progress on my prototype implementation of
a new layout approach, I am not likely to get any practical results
before some time (a year or more). Meanwhile, users keep bumping into
this Changing IPD issue, which is
Martin Edge wrote:
Yes there are people here listening but at least 2 regular developers
are on holidays ATM so thats why responses might be slow or lacking.
Need some help understanding why the trunk does not behave properly when
dealing with missing fonts.
I used to have Metric files to
Lars Andren wrote:
Hi all,
Hi Lars,
When I am generating a PDF-file, the class LineBreakUtils and the method
public static byte getLineBreakPairProperty(int lineBreakPropertyBefore,int
lineBreakPropertyAfter) {
return
PAIR_TABLE[lineBreakPropertyBefore-1][lineBreakPropertyAfter-1];
Vincent Hennebert wrote:
Hi Simon,
Hi Simon, Vincent,
The report looks good. Just a thing about the ChangingIPD hack: actually
it is still undecided whether it should be merged back to Trunk or not.
My main concern about that is that it will get in the way when
implementing the new
Vincent Hennebert wrote:
Hi All,
Thanks for starting the vote Vincent.
Having had no feedback from the users list, I’m happy to announce that
the ChangingIPDHack branch is now totally bug-free :-)
Following the discussion on general@ [1], the best way to handle this
probably is to merge
Vincent Hennebert wrote:
Hi Vincent,
I’d say it the other way round: I think that there is no compelling
reason to switch to Java 1.6. Apart maybe from the internationalization
area, the improvements made in that version are not likely to be that
much of a benefit for FOP to justify the jump.
Jonathan Levinson wrote:
Hi,
Hi Jonathon,
My management has asked me to volunteer to help fix FOP bugs and add FOP
enhancements. I’m not yet familiar with FOP internals though I’ve read
your design documents.
Good news indeed. FOP is short on development resources. I take it you
have
Vincent Hennebert wrote:
Hi,
Hi Vincent,
Work on PDF accessibility is basically done. There are still some tests
to perform and maybe a few tweaks here and there, but the main
functionality is in place.
Thanks for all your hard work getting this feature debugged and cleaned up.
So I’d
Domján Gergő wrote:
Hi Everyone,
Hi Domjan,
I think, I have found a bug.
I want to use FOP to convert xsl-fo files into txt files with layout.
I experienced, that the layout is distorted because the max column
number is set to 80 by default. I wanted to change this value using a
config
acumis...@apache.org wrote:
Author: acumiskey
Date: Thu Oct 22 13:20:53 2009
New Revision: 828678
Hi Adrian,
there is a bug in this commit. AttributeQualifier was moved from end of
TLE to be between Attribute Name and Attribute Value.
I will commit a fix shortly.
Chris
URL:
Attribute Qualifier is the last part of TLE structured field.
One of our customers has a process that extracts the TLE values which
now fails because the 10 bytes of the AttributeQualifier occur in front
of the value.
Thanks,
Chris
Thanks,
Adrian.
2009/11/26 Chris Bowditch bowditch_ch
Adrian Cumiskey wrote:
Hi Chris,
Hi Adrian,
thanks for your input on this. It is appreciated.
2009/11/26 Chris Bowditch bowditch_ch...@hotmail.com
mailto:bowditch_ch...@hotmail.com
Adrian Cumiskey wrote:
I agree it might be better if the AttributeQualifier triplet
Stephan Thesing wrote:
Dear all,
sorry for the long delay in answering.
Hi Stephan,
thanks for looking into this! Change bars would be a useful feature
addition to FOP.
Having had some time in the last days to actually continue working
on the change bar stuff:
+ parsing and validating
Archie144 wrote:
Hi,
I m using fop 0.20.5 version.
That's a 6 year old release and no longer supported
I am having trouble in legends in JFreechart in pdf in Chinese language.
Please don't cross post to multiple lists. The fop-user list is the
correct list to ask questions.
I am using
Simon Pepping wrote:
Hi Simon,
On Tue, May 11, 2010 at 09:41:28AM -, Apache Wiki wrote:
PostScript since PS supports CFF fonts (Type 2 fonts). However, I don't
know if there are any insurmountable differences between PS CFF support
I is Chris here?
I believe Jeremias wrote that
101 - 200 of 692 matches
Mail list logo
