Hi,
what was that boolean supposed to do, given that it’s set to false by
default, never set to true and results into dead code in renderSpace and
renderText?
Thanks,
Vincent
Hi Tom,
(FWIW, I think this list is appropriate for this discussion as it has to
do with enhancing FOP.)
Tom Browder wrote:
I would like to be able to use a Hangul (Hangeul: Korean) Open Type
font with fop.
I have found the Unifoundry and it has Hangul fonts in bfd format.
The licensing
Hi,
Jeremias Maerki wrote:
On 05.07.2010 17:13:32 Simon Pepping wrote:
snip/
In compliance, I kept only 0.95, 1.0 and trunk. This caused extensive
changes to comments.
I guess keeping track of various versions on the website is one of the
biggest issues why doing FOP releases is so hard. I
Vincent Hennebert wrote:
Hi Jeremias,
Jeremias Maerki wrote:
Hi Vincent,
hmmyes, that's tricky. An (atend) requires a corresponding comment in
the end, but resources is defined to provide at least one item. An
ugly work-around would be to always list Helvetica as needed resources
Hi,
The PostScript Document Structuring Conventions Specification states
that the %%DocumentNeededResources: comment can be specified in the
%%Trailer section, but if this is the case it must also be present in
the header with an (atend) value.
complaints about DSC comments that caused
trouble AFAICR.
I guess using a document manager goes in pair with optimizing the
PostScript output anyway.
Thanks,
Vincent
On 25.06.2010 13:07:51 Vincent Hennebert wrote:
Hi,
The PostScript Document Structuring Conventions Specification states
Hi,
Following Jeremias’ notes about implementing support for TrueType fonts
in PostScript:
http://wiki.apache.org/xmlgraphics-fop/TrueTypeInPostScript
I’d like to give it a go. I will create a branch shortly and work from
there. Any help or comments would be most welcome, as I’m mostly
supporting
characters beyong the basic plane. So unless there is a sustained veto
against rev 946585 I'm inclined to leave it like it is.
On 21.05.2010 11:46:42 Vincent Hennebert wrote:
Hi,
Author: jeremias
Date: Thu May 20 09:52:27 2010
New Revision: 946585
URL: http://svn.apache.org/viewvc
Hi,
Author: jeremias
Date: Thu May 20 09:52:27 2010
New Revision: 946585
URL: http://svn.apache.org/viewvc?rev=946585view=rev
Log:
Changed many variables and parameters from int to char because AFP font
support mostly uses Unicode code points unlike Type 1 and TrueType support
which
Simon Pepping wrote:
On Wed, Mar 24, 2010 at 07:37:12PM +, Vincent Hennebert wrote:
Speaking of the release, many parts of the website are largely outdated
and need a serious re-work (the Development tab, mainly). Also, any
reference to 0.20.5 should IMO be removed before releasing 1.0
Hi,
Adrian Cumiskey wrote:
HI Simon,
I'm not sure it would, a very complex subject that would require a lot of
time just to understand all the considerations involved. There is a good
reason why it has not been implemented up to now.
Agreed. The table code is too complicated and would
Hi Simon,
Simon Pepping wrote:
Thanks to Adrian and Vincent who want to be mentor. We also need some
ideas for projects.
1. Our releases require too much work, which has resulted in no
release for much too long a time. How can the work related to a
release be minimized? Can we develop
Hi,
Pascal Sancho wrote:
Hi,
I partially agree, but...:
- both releases (0.94: 2007, 0.95: 2008) are posterior to REC 1.1 (2006);
- both releases implement some REC 1.1 new features (Cf. bookmarks).
I can revert the change, but that will not reflect the above things, IMHO.
WDYT?
I
Pascal Sancho wrote:
You are right, Simon.
I've tried to commit deployment by hands, and it's OK.
I have to investigate why ForrestBot did not.
FWIW, ForrestBot has never worked for me. From the quick investigation
I made (it was a long time ago), the parsing of the ‘svn st’ it was
doing to
Hi Mathieu,
Mathieu Malaterre wrote:
[previously sent in fop-user mailing list]
hi there,
This is my first post to fop-dev, it is suggested to report bug here.
Actually bug reports should be made on Bugzilla:
https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop
Please could you
/fop/dev/doc.html#web
Feel free to ask here if you have any question.
Thanks,
Vincent
Pascal
Vincent Hennebert a écrit :
Hi Pascal,
Author: psancho
Date: Mon Feb 15 15:43:32 2010
New Revision: 910239
URL: http://svn.apache.org/viewvc?rev=910239view=rev
Log:
Added complete list
Hi Pascal,
Author: psancho
Date: Mon Feb 15 15:43:32 2010
New Revision: 910239
URL: http://svn.apache.org/viewvc?rev=910239view=rev
Log:
Added complete list of 1.1 item in compliance page.
- Udated information for page-number-citation-last, content-width,
content-height, and
Hi Jeremias,
Author: jeremias
Date: Wed Feb 10 15:37:04 2010
New Revision: 908543
URL: http://svn.apache.org/viewvc?rev=908543view=rev
Log:
Bugzilla #48512:
Bugfix: Don't map AdobeStandardEncoding to StandardEncoding. They are not the
same. Fixes problem with invalid character widths
Hi Martin,
Martin Edge wrote:
Within eclipse it says it's within the 'build path' or do you mean within
Java's class path?
You need to refresh the directory for Eclipse to take into account new
files created by the build process.
Select the project in the Package Explorer view and press
Hi,
FYI, I’ve just committed a fix for this bug:
http://svn.apache.org/viewvc?rev=904467view=rev
If you ever need to you can apply the patch to FOP 0.95’s source code as
is.
As a side note, introducing a new object just for synchronization
purpose is not necessary. The class object
Hi Simon,
Simon Pepping wrote:
From a FontBox report: We are still working on integrating Villu's
patch which adds support for Adobe CFF/Type2 fonts to FontBox.
This raises my question: Can we share font handling code with FontBox?
A priori yes. Our own font code definitely needs
Hi Stephan,
I’m not sure I would invest any energy into improving the
CachedRenderPagesModel (-conserve option). It doesn’t look like the
right approach to me, and like you noticed it doesn’t even work out of
the box currently.
Why store the Area Tree on disk? Why not directly render it into the
Hi Simon,
Simon Pepping wrote:
On Wed, Jan 13, 2010 at 05:17:03PM -, vhenneb...@apache.org wrote:
Author: vhennebert
Date: Wed Jan 13 17:17:01 2010
New Revision: 898845
URL: http://svn.apache.org/viewvc?rev=898845view=rev
Log:
Updated reference accessible PDF files. Old ones had
Hi,
Looks like Max is busy with more urgent things :-)
As this patch will affect my future work on the layout engine, I’d like
to take over the patch review.
Your suggestion to use Skype sounds good. That will ease the job a bit.
I’ll contact you off-line to exchange details and arrange a time.
Hi,
Just a few precisions:
Jeremias Maerki wrote:
On 22.10.2009 21:15:40 Simon Pepping wrote:
snip/
Can you summarize what the branch tries to achieve?
I'll try. In short: it provides the Tagged PDF feature that some people
have always wanted.
Long story: Without the
Vincent Hennebert wrote:
Hi,
snip/
There's another side-effect to tagged PDF: It allows for better text
extraction from the document. PDF even describes ways to make
round-trips from XML - PDF - XML - PDF if certain conditions were met.
However, we don't do that.
Speaking
Hi,
Log:
Issue an error when attempting to render an intermediate XML file in
accessibility mode, but that file wasn't generated with accessibility (i.e.,
does not contain the structure tree)
Added:
Hi Simon,
Simon Pepping wrote:
On Tue, Oct 20, 2009 at 10:04:09AM -, vhenneb...@apache.org wrote:
Author: vhennebert
Date: Tue Oct 20 10:04:09 2009
New Revision: 827023
URL: http://svn.apache.org/viewvc?rev=827023view=rev
Log:
Fixed checkstyle issues.
Factorized duplicated code into
Hi,
Just a nit:
+private boolean useCatalogResolver = false;
+private EntityResolver entityResolver = null;
+private URIResolver uriResolver = null;
Those fields are being initialized to their default values. The Java
Language Specification states [1] that every field must be
Hi,
In doubt, I added them, but is it actually necessary to put license
headers in such test files? The header is bigger than the actual
content...
Vincent
Added:
xmlgraphics/fop/branches/Temp_Accessibility/test/accessibility/background-image_jpg_repeat.fo
URL:
over
the Barcode XML - SVG implementation in the PDF case. But that will
only be triggered with the new IF. With the renderer, I assume (without
checking) the XMLHandler interface will be used.
On 15.10.2009 17:51:01 Vincent Hennebert wrote:
Hi,
I tried every image format I could think
Hi,
I tried every image format I could think of, none triggers the use of
PDFImageHandlerGraphics2D. AFAIU this is the only image handler that
doesn’t call PDFRenderer.placeImage or renderDocument in return, in
which accessibility is handled. So if that handler is used the generated
PDF will be
of the parser. Unless we
decide to use both the lexer and parser anyway...
Vincent
Best Regards,
Jonathan S. Levinson
-Original Message-
From: Vincent Hennebert [mailto:vhenneb...@gmail.com]
Sent: Wednesday, October 07, 2009 6:51 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re
Hi Jonathan,
Jonathan Levinson wrote:
I noticed that if one is not careful in one's regular expression use,
the compilation for a regular expression can take minutes. I'm not
talking about applying the pattern just compiling it!
Should regular expressions be avoided altogether and
Hi,
If I render the attached FO file into IF XML with the attached
configuration file, then render the xml file into PDF, then I get the
following error:
SEVERE: Exception
java.lang.NullPointerException: fontName must not be null
at
While I'm at it, and taking the same FO file and config file: specifying
a mime type for the intermediate format doesn’t seem to work, contrary
to the area tree. Take the config file, remove the part corresponding to
the intermediate format (renderer
mime=application/X-fop-intermediate-format),
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
To reproduce: put the config file at the root of a FOP local copy, then
run the following:
fop -c config.xconf test.fo -if if.xml
fop -c config.xconf -ifin if.xml test.pdf
I would like to run your example this way, but there is no
Hi Alexander,
I can’t really help I’m afraid, as I personally don’t have the necessary
knowledge. It’s probably time to submit what you already have as a patch
attached to a Bugzilla entry:
https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop
That will allow us to have a look and maybe
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,
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
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
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
)
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
Hi Jonathan,
Jonathan Levinson wrote:
Hi Vincent,
Excellent ideas!
The diagram you drew is extremely useful!
If the font shorthand sub-language has a grammar that is regular then it also
has a grammar that is LL(1). So recursive descent parsing will work, if
there is a regular
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
I see. I had in mind to use OpenTypeDataInputStream as the common
interface. It actually makes sense to use ImageInputStream instead.
Simpler and just as flexible. That will add a direct dependency on
a class in the javax.imageio package, but
Hi Alexander,
Alexander Kiel wrote:
Hi Max,
First, I will respect every code style of FOP. Its just a matter of
discussion.
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
of it. If
a choice had to be made between ANTLR and JavaCC, which one would win?
JavaCC is BSD license, so we could easily integrate it in the fop build.
Max
Thanks,
Vincent
2009/9/28 Vincent Hennebert:
Hi Jonathan,
Interesting stuff!
Jonathan Levinson wrote:
Hi Vincent,
snip/
Because font
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
Here are my two cents: if you make use of classes in javax.imagio at
only one place in your font library, then there’s no need to worry about
creating a more neutral layer. If OTOH you need to use those classes
everywhere, then it makes sense
Hi Max,
Max Berger wrote:
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 :)
If you think
Hi Max,
Max Berger wrote:
Vincent,
2009/9/29 Vincent Hennebert:
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
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
I had a look at SeekableStream and I can imagine how the needs resulted
in the ImageInputStream interface. I haven't decided yet if I should use
ImageInputStream directly. Maybe someone else can throw it's two cents
in here.
Here are my two
Hi,
Jeremias Maerki wrote:
On 27.09.2009 13:27:35 Alexander Kiel wrote:
Hi Jeremias,
Makes sense. I stumbled over that myself from time to time but it didn't
really bother me so much to take action.
Okay. Can you please modify the checkstyle XML files to reflect that?
Sure, but only
Hi Guys,
Maybe a bit late, but you may find the following page interesting:
http://wiki.apache.org/xmlgraphics-fop/FOPIntelliJSetup
Feel free to make any additions or corrections to this document.
As to the use of checkstyle: I think the rules were set up long after
the project was created. So
Hi Carlos,
Carlos Villegas wrote:
Hi,
I searched the mailing lists and it seems that although some people had
worked at several times at trying to implement retrieve-table-marker,
it's not yet done. Is somebody working on this? What's the status?
It’s not being worked on at the moment.
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
startPageSequence when the first page tag
is encountered.
That’s what I ended up doing.
Thanks for your input,
Vincent
On 24.09.2009 13:07:11 Vincent Hennebert wrote:
Jeremias Maerki wrote:
Not just like that (if at all). The content items being produced inside
the page-sequence have to be linked
Hi Alexander,
Knowing just about nothing of font file formats and libraries, I’ll play
the ignorant guy asking naive questions, hoping that it might give you
good ideas.
Alexander Kiel wrote:
Hi Jeremias,
On Fri, 2009-09-25 at 08:37 +0200, Jeremias Maerki wrote:
I don't think that relying
Vincent Hennebert wrote:
To those PDF specialists around here: am I right that the structure tree
could as well be converted into PDF at the end of a page sequence, as at
the beginning?
In other words: could the piece of code dealing with the structure tree
be moved from
Hi Tony,
Tony Graham wrote:
On Mon, Sep 21 2009 23:30:17 +0100, jonathan.levin...@intersystems.com wrote:
...
If inherit is allowed to be a value then the grammar truly becomes ambiguous
since each of these can have the value inherit and we don?t know which ones
are
omitted and must take
To those PDF specialists around here: am I right that the structure tree
could as well be converted into PDF at the end of a page sequence, as at
the beginning?
In other words: could the piece of code dealing with the structure tree
be moved from PDFDocumentHandler.startPageSequence to
Hi Jonathan,
Jonathan Levinson wrote:
Hi Vincent,
As I read the grammar for the font shorthand it is ambiguous, though not
fatally so as long as one excludes the value of inherit from
individual properties in the font short hand.
For instance the first optional argument is
Hi Alexander,
Alexander Kiel wrote:
Hi Max,
thanks for pointing me to fontbox. As I did not find a repository with a
trunk, I had a look into fontbox-0.8.0-incubating. They have quite clean
code to parse TrueType files. But they are also not able to read any
OpenType data. They are even
Hi Jonathan,
Jonathan Levinson wrote:
Hi Vincent,
You make excellent points, however for font-style, font-variant and
font-weight the initial value (the default value) is normal, not inherit.
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#font-style
Hi,
It may also be interesting to have a look at ICU4J [1]. I think this
dependency will be necessary anyway if we are serious about implementing
complex scripts. There may be stuff there that would avoid us
re-inventing the wheel.
[1] http://site.icu-project.org/
Vincent
spepping leverkruid
Hi,
does anyone know why the o.a.f.apps.Fop.getDefaultHandler method returns
an instance of org.xml.sax.helpers.DefaultHandler and not just an
org.xml.sax.ContentHandler? Could that be changed?
Thanks,
Vincent
Hi Stephan,
Stephan Thesing wrote:
Hello,
snip/
My idea is now along the following lines:
- Remember for each element during parsing the change bars it is
influenced by.
- After layout, go over all areas produced by those influenced elements
and add the areas for the change bars
Hi Stephan,
Stephan Thesing wrote:
Hello,
just a short status / question update.
snip/
What remains is layout and producing the change bar areas.
If I read the spec right, the intended semantics of the change-bar-elements
is the following:
- for all elements generating areas that
Author: vhennebert
Date: Wed Aug 26 17:42:11 2009
New Revision: 808135
URL: http://svn.apache.org/viewvc?rev=808135view=rev
Log:
Reverted changes made in revision 796809 (manual merge of clean-up changes
made in the ChangingIPDHack branch). Those changes will be re-applied when
merging
Hi Clay,
The Web Maestro wrote:
I agree about consistency w requirements... Perhaps one additional
release req 1.4, then move to 1.5 for the next release. I don't have
any real energy about whether the 1.0 should be 1.4 or 1.5, however...
I do agree that there should be a significant version
Time for the results: 7 +1, no negative vote. The vote passes.
I’ll proceed with the merge in the next days.
Thanks,
Vincent
Vincent Hennebert wrote:
Hi All,
Having had no feedback from the users list, I’m happy to announce that
the ChangingIPDHack branch is now totally bug-free
Hi Simon,
Simon Pepping wrote:
On Wed, Aug 19, 2009 at 08:44:03AM +0200, Jeremias Maerki wrote:
Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
now on Java 1.4. OK if we revert until you've had a chance to revisit?
I am surprised. My eclipse project is set to 1.4
Hi All,
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 the changes back into the Trunk, even if they are
hacky. Maintaining a
Adrian Cumiskey wrote:
Hi all,
Maybe its time we moved to 1.5 like the rest of the world. Max, Vincent
and Andreas, myself and others were all in favour of the switch in June
2008 (see http://www.nabble.com/Switching-to-Java-1.5-td17673100.html).
Sun's end of life transition period for
Hi Simon,
Simon Pepping wrote:
Vincent,
On Wed, Aug 05, 2009 at 10:37:13AM -, Apache Wiki wrote:
+ No releases this quarter. A provisional solution for changing IPD (page
width) has been developed in a branch. This solution works only for simple
cases and is more a hack than anything
Hi Simon,
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 approach. I will basically have to start with
reverting
Hi,
Vincent Hennebert wrote:
Hi Simon,
Thank you for giving a go at testing the branch. I could reproduce the
hyphenation and flow_changing-ipd_4.xml problems. Regarding the stretch
issue, could you send me a sample FO file? I suspect that this may be
normal in the sense that the layout
Hi Simon,
Thank you for giving a go at testing the branch. I could reproduce the
hyphenation and flow_changing-ipd_4.xml problems. Regarding the stretch
issue, could you send me a sample FO file? I suspect that this may be
normal in the sense that the layout policy is slightly different when
[Sent on behalf of the Travel Assistance Committee.]
Original Message
The Travel Assistance Committee is taking in applications for those wanting
to attend ApacheCon US 2009 (Oakland) which takes place between the 2nd and
6th November 2009.
The Travel Assistance Committee is
Hi All,
I’m basically finished with the implementation of the hack to handle
pages of different widths. As a remainder, tables and lists aren’t
supported; this means that they will flow on the new page without taking
the new width into account. So if there is a switch between e.g.
a landscape
Andreas Delmelle wrote:
On 07 Jul 2009, at 17:55, Vincent Hennebert wrote:
Hi Vincent
.. Another leak from the keep-within-column patch?
Indeed, but this one I caught soon after committing, so is already undone.
Of course. Stupid me :-|
Thanks, and sorry about the noise.
Vincent
Hi Andreas,
The changes generally look good. I just have two small questions:
Author: adelmelle
Date: Wed Jul 1 13:52:20 2009
New Revision: 790166
URL: http://svn.apache.org/viewvc?rev=790166view=rev
Log:
Further cleanup/readability improvements
@@ -550,31 +563,33 @@
Hi Andreas,
Andreas Delmelle wrote:
On 07 Jul 2009, at 13:54, Vincent Hennebert wrote:
Hi Vincent,
splitLength += element.getW();
} else {
// element is a penalty
-if (element.getP
Hi Andreas,
Again, most of the clean up looks good, only...
Author: adelmelle
Date: Sat Jul 4 17:00:05 2009
New Revision: 791153
URL: http://svn.apache.org/viewvc?rev=791153view=rev
Log:
Further cleanup/readability improvements
Modified:
Hi Andreas,
Andreas Delmelle wrote:
On 23 Jun 2009, at 17:50, vhennebert apache org wrote:
Author: vhennebert
Date: Tue Jun 23 15:50:15 2009
New Revision: 787733
URL: http://svn.apache.org/viewvc?rev=787733view=rev
Log:
Code clean-up
snip /
Hi,
Andreas Delmelle wrote:
On 18 Jun 2009, at 20:26, Simon Pepping wrote:
Hi Simon, Vincent,
snip /
I get the feeling that this means that you are planning to relaunch
line breaking while in the page breaking phase.
Yes.
Is that possible?
That’s what I am currently trying to figure
Hi Simon,
Simon Pepping wrote:
Shouldn't you be doing this in trunk? Simon
I guess I could, but I’m doing the changes as I go along the code to
figure out what I have to do where. Switching back and forth from a copy
of the Trunk to a copy of the branch would be tedious.
Even if the branch
Hi All,
While creating the new branch for (what I’ll be calling from now on)
Changing IPD Hack, I noticed the many branches that already exist and
that reminded me of an old conversation we had about that:
http://markmail.org/thread/mpcse3cgvdlgfi5u
If that’s ok for everyone I’ll move the
Hi Andreas,
Andreas Delmelle wrote:
On 11 Jun 2009, at 12:40, Vincent Hennebert wrote:
Hi Vincent
snip /
I spent some time looking at the current code and it seems to me that
a hack could be implemented without too many difficulties. It basically
consists in 2 steps:
1. in the Knuth
Hi All,
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 becoming more and more problematic.
It
Hi Chris,
Chris Bowditch wrote:
Vincent Hennebert wrote:
Hi All,
Hi Vincent,
snip/
Obviously this is a limited approach. There is likely to be
a (potentially huge) waste of CPU cycles due to the re-creation of Knuth
elements. There may be side effects that I’ve missed so far. But I
Hi Ben,
Thank you very much for your interest in FOP and your contribution. I’ve
opened a Bugzilla issue containing your patch so that it can easily be
referred to:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47314
It is likely to interest other users who run into similar memory issues,
Hi Guys,
Andreas Delmelle wrote:
On 29 May 2009, at 20:55, Simon Pepping wrote:
Hi Simon, Vincent,
planned. Furthermore, we are in the process of bringing major changes to
the layout engine in order to be able to handle pages of different
widths. So any work on the current code is likely
Hi,
(All of the developers have subscribed to the fop-users mailing list, so
if they didn’t answer there that means that they simply don’t have the
answer unfortunately.)
Have you asked on the Barcode4J mailing list? Maybe they can provide you
with more help there. At any rate an
Hi Adrian
Author: acumiskey
Date: Tue May 5 16:06:43 2009
New Revision: 771874
URL: http://svn.apache.org/viewvc?rev=771874view=rev
Log:
Added tip for reducing memory consumption.
I’m not sure this addition is really necessary. The tip about using many
page sequences is already
Hi,
Author: jeremias
Date: Fri Apr 3 07:44:09 2009
New Revision: 761554
URL: http://svn.apache.org/viewvc?rev=761554view=rev
Log:
Fixed a bug that left the PrintRenderer unconfigured even if a configuration
was specified for application/X-fop-print.
snip/
+/** {...@inheritdoc}
?
Vincent
On 03.04.2009 11:40:20 Vincent Hennebert wrote:
Hi,
Author: jeremias
Date: Fri Apr 3 07:44:09 2009
New Revision: 761554
URL: http://svn.apache.org/viewvc?rev=761554view=rev
Log:
Fixed a bug that left the PrintRenderer unconfigured even if a
configuration was specified
Hi Adrian,
Author: acumiskey
Date: Tue Mar 24 15:39:15 2009
New Revision: 757852
URL: http://svn.apache.org/viewvc?rev=757852view=rev
Log:
Added some nice bean methods for pageSequenceMaster and simplePageMaster,
this also makes startOfNode() easier to read too.
Modified:
Author: jeremias
Date: Tue Mar 24 08:08:54 2009
New Revision: 757681
URL: http://svn.apache.org/viewvc?rev=757681view=rev
Log:
Amendment to revision 755894:
The mimicking fix didn't work for all output formats.
snip/
Modified:
Hi Andreas,
Andreas Delmelle wrote:
On 23 Mar 2009, at 13:12, vhennebert wrote:
Author: vhennebert
Date: Mon Mar 23 12:12:36 2009
New Revision: 757382
URL: http://svn.apache.org/viewvc?rev=757382view=rev
Log:
Set svn:eol-style property on
301 - 400 of 801 matches
Mail list logo
