We are. Luca commented on how we can make a total-fit behave like a
best-fit/first-fit.
On 11.03.2005 00:14:24 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > A fact is that FOP 0.20.5 had no problems with differing
> > available IPDs.
> > With Luca's sug
On 10.03.2005 16:15:10 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > I got my copy of Michael Plass' dissertation today. A cursory
> > overview shows that this document will provide some insight
> > on using Knuth element model for page breaking but it also
g, but I'd feel better.
Jeremias Maerki
ource/jai/
> [2]
> http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/
> [3]
> http://mail-archives.eu.apache.org/mod_mbox/xmlgraphics-general/200503.mbox/[EMAIL
> PROTECTED]
> [4] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=10756
Jeremias Maerki
deal with back then. At any rate, the dissertation seems
more helpful than the two documents we found by Brüggemann-Klein, Klein
and Wohlfeil.
Jeremias Maerki
then have several examples on how to adjust the bitmap renderer for
themselves. And a additional JAI implementation is certainly not a big
deal after we have the first one.
On 09.03.2005 16:38:33 Oleg Tkachenko wrote:
> Jeremias Maerki wrote:
>
> > That's no problem, I thin
Yes, please, because it's a lot easier to handle inside an IDE. You
simply define an additional source folder if you're on JDK 1.4, and you
don't get compile error on JDK 1.3.
On 09.03.2005 16:34:39 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
:43:57 Luca Furini wrote:
> Jeremias Maerki wrote:
>
> > Luca, do you think your total-fit approach may be written in a way to
> > handle changing available IPDs and that look-ahead can be disabled to
> > improve processing speed at the cost of optimal break decisions?
>
On 09.03.2005 12:51:11 Renaud Richardet wrote:
> I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer.
> Jeremias, you mean that we can legally just put those in the FOP-code?
This would have to be checked out. I'd rather not, especially when we
have PNG and TIFF cod
er B. West wrote:
> That will be extremely useful. However, I was trying to clarify the
> situation of PDFRenderer. The impression I got from Renaud's comment
> was that the Java2DRenderer was to be the basis of all renderers. Hence
> my interest.
Jeremias Maerki
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/
On 09.03.2005 11:30:51 Oleg Tkachenko wrote:
> Jeremias Maerki wrote:
>
> > Thanks to Glen for raising the issue. The ideal approach is if Oleg
> > would pack up his TIFFRenderer and do
grate it
> > yourself? Otherwise I
> > would like to do it.
> >
> > Regards,
> > Renaud
> >
> > [1]
> > http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> > [2] http://www.tkachenko.com/fop/fop.html
> >
Jeremias Maerki
ot;, what will
> the relationship to the concrete PDF renderer be? The wiki is vague on
> this point.
Jeremias Maerki
ion/awt" to
"application/X-awt".
[1] http://www.faqs.org/rfcs/rfc2045.html
On 09.03.2005 01:31:24 Glen Mazza wrote:
> The "application/awt" MIME type doesn't exist. I
> think Jeremias wanted this to be null instead for
> output types that lack a MIME type, corr
By the way, Renaud, you should sign and send an ICLA (Individual
Contributor license agreement) to the ASF if you haven't done so already.
http://www.apache.org/licenses/#clas
Just so we're on the safe side. After all you're not just doing little
bug fixes. Thanks!
Jeremias Maerki
On 08.03.2005 03:18:21 Renaud Richardet wrote:
> On Mon, 28 Feb 2005 , Jeremias Maerki wrote:
>
> > > AbstractRenderer: I moved what I could reuse from PDFRenderer to
> > > AbstractRenderer: renderTextDecorations(), handleRegionTraits(), and
> > > add
Cool, that would be great stuff. Let's hope your boss lets you off the
leash.
On 07.03.2005 23:57:50 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I was also thinking about something like
> > "hidden treasures in the XML Graphics project" but I guess there'
t; to ask you if our impression is correct. We have nowto decide if we
> change from FOP to XEP or XSL-Formatter.
>
> Thanks for your help, Michael
>
>
> Michael Iwaniewicz
> CHIS Architecture
> Office: (43-1) 21145-6446
> Mobile:(43) (0) 664-618-5839
Jeremias Maerki
not
so much meat on that bone to fill one hour.
> ApacheCon Europe 2005 CFP submission
>
> Submitter: Jeremias Maerki <[EMAIL PROTECTED]>
> Title: Apache FOP: Optimizing speed and memory consumption
> Level: Experienced
> Style:
> Orientation: Developer
> Duratio
I don't know why this is important to you but it's two to three months.
On 04.03.2005 12:40:04 Peter B. West wrote:
> Jeremias Maerki wrote:
> > Sounds very interesting. Would you consider sharing what you already
> > have? This may help us in the general discussion and m
le elements for the
PageLM.
Some more comments inline:
On 04.03.2005 13:23:01 Luca Furini wrote:
>
> Jeremias Maerki wrote:
>
> >Would you consider sharing what you already
> >have? This may help us in the general discussion and may be a good
> >starting point.
>
>
of time.
On 04.03.2005 11:09:42 Luca Furini wrote:
>
> Jeremias Maerki wrote:
>
> >Anyway, I'd like to ask if we could hold to a brainstorming conference
> >call on page breaking either Sunday evening or next Monday or Tuesday
> >somewhere between 8:00 and 24:00
Ok then, I'll call you Sunday evening 19.00 CET if nothing goes wrong.
The others interested will find me in Skype.
FYI, I'll be out of touch from later today until Sunday afternoon.
On 03.03.2005 21:46:55 Simon Pepping wrote:
> On Thu, Mar 03, 2005 at 08:34:54PM +0100, Jeremias
27;s another article, where the top level of the algorithm is
> presented (page 8).
> http://www.pi6.fernuni-hagen.de/publ/tr205.pdf
>
> Those 2 articles are summaries of a book. The link to command the book
> can be found at the bottom of
> http://web.informatik.uni-bonn.de/I/research/Pagination/
>
> Renaud
Jeremias Maerki
ontribute, of course. Max. number in the conference is four people with
Skype.
On 01.03.2005 23:31:16 Jeremias Maerki wrote:
> Maybe I could hook you into a Skype conference by using SkypeOut. It's pretty
> cheap to call to the Netherlands. According to the FAQ this is possible.
>
>
o see how you have reprioritized your efforts
> over the past two months [1], and much, much for the
> better.
>
> Glen
>
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
> > I very much hope so. But it becomes more and more
> > apparent that this
&g
On 03.03.2005 16:19:24 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > While looking for material on page breaking I found several
> > references to this document:
> >
> > http://wwwlib.umi.com/dissertations/fullcit/8124134
> >
> > Does anyone know
no break, the overall bpd is (hH + hA + h1 + hN + h2 + hB +
> hF), otherwise the first piece has bpd (hH + hA + h1 + hB + hF) and the
> second one (hH + hA + h2 + hB + hF), and the border between the rows is
> ignored.
>
> The elements representing the header and its border are moved at the end
> of the sequence, but I don't think this is could be a real problem: the
> TableLayoutManager would place it at its right place when adding areas.
>
> Regards
> Luca
>
Jeremias Maerki
d download immediately for a reasonable fee.
Thanks,
Jeremias Maerki
present approach was very
good to point us in the right direction and most of the effort already
invested is not lost. We just have to improve a specific part.
Jeremias Maerki
27;t already be so due to
> free-flowing (i.e., first-fit) text. Everything would
> become free-flowing in order to obey the stylesheet
> writer's specifications.
>
> Just my $0.02.
>
> Thanks,
> Glen
>
> [1]
> http://www.w3.org/TR/2001/REC-xsl-20011
nning going to result in an algorithm that
> will help us do this?
Jeremias Maerki
; > alt-design, which eventually moved to source
> > forge!!!
> >
> > Chris
> >
>
> Either way is fine with me, but Chris brings up a very
> valid point. If you can tolerate and keep up with my
> minor code housekeeping from time to time in some of
> the layout managers (currently mostly PSLM), feel free
> to work from HEAD directly instead if you wish.
>
> Glen
Jeremias Maerki
Maybe I could hook you into a Skype conference by using SkypeOut. It's pretty
cheap to call to the Netherlands. According to the FAQ this is possible.
On 01.03.2005 22:26:50 Simon Pepping wrote:
> On Tue, Mar 01, 2005 at 03:09:46PM +0100, Jeremias Maerki wrote:
> > To speed thin
On 01.03.2005 22:25:12 Simon Pepping wrote:
> On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> > Jeremias Maerki wrote:
> >
> > > processing time and additional memory requirements. This
> > > leads me to the question if we shouldn't actua
ce-before after the page-break, hw is the space when there is no
> +page break.
Jeremias Maerki
good. Do you mean something like the "Bitmap production"
> you documented on FopAndJava2D [1]? This is what I intend to work on
> after the basic Java2DRenderer works.
Yes, exactly, at least for the AWT/Java2DRenderer. For PDF and PS you
need to use GhostScript for the conversion.
Jeremias Maerki
To speed things up could we hold a conference (using Skype, for example)
to discuss further details on page-breaking? I'd volunteer to sum up any
results during that discussion for the archives. I have Finn on my Skype
radar already.
Jeremias Maerki
me of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since I don't want to work with a series of patches like
you guys did earlier, I'd like to create a branch to do that on as soon
as we've agreed on a strategy. Any objections to that?
[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout
Jeremias Maerki
o potential for disagreements.
On 28.02.2005 19:33:05 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Thanks for bringing this up. I almost forgot.
> >
> > I'd be in favor of integrating Victor's improvements in this area.
> > However, I'd also be inclined to
messing with fonts at all, I highly recommend that
> FOray be implemented before doing anything else. I will be happy to support
> efforts to that end.
Jeremias Maerki
ight direction. I'm looking forward to
committing your changes when you're happy with the results.
Another thought: One of my low-priority tasks is to create a little
application that renders a test suite with all of FOP's renderers
creating bitmap images for each generated document and ultimately
creating a little website that lets us compare the output. PDFs and PS
files can be converted to bitmaps using GhostScript. Maybe you might
want to write such a thingy. I won't get to it before I get to updating
the PS renderer to full quality.
Jeremias Maerki
ple who don't read
> the README file, but learning a little about Ant--if
> only the fact that they need to type "ant"--is
> probably a Good Thing for them anyway.
>
> Thanks,
> Glen
Jeremias Maerki
7;s just a short message.
> Jeremias, I gave you a full, thorough, and
> respectfully written explanation of the issues
> involved. Not only did you mostly ignore it, but in
> your response you chose to use my earlier smaller
> email in order to give others the impression that I
> ha
to have to
work around them.
I have nothing more to say about this. I want to spend my time on more
productive things now.
On 24.02.2005 00:01:05 Glen Mazza wrote:
> Jeremias,
>
> This should not be done. If someone has a problem
> with it--and I've never heard a complaint--they
.
On 22.02.2005 22:43:01 Renaud Richardet wrote:
> Glen Mazza <[EMAIL PROTECTED]> wrote:
> > Looks good! Now whether you wish to do this before or
> > after Renaud moves the logic over is up to you two.
> > There's advantages/disadvantages to either method.
> yes, that lo
e on the simple things first. No need to worry about the
writing mode already. The reference orientation is simple. It's just a
matter of getting the transformations right. Run the simple test cases
from the layout engine test suite and work from simple to more
complicated.
Jeremias Maerki
wouldn't it be easier to record the absolute position of an
> area during the page-breaking process? or am i missing something?
>
> renaud
>
> PS: the abstract Java2DRenderer sounds like a really good deal to me :)
Jeremias Maerki
the wrong name.
The new layout also doesn't require that I prepare the ground for Renaud.
Also, I hope this Wiki page helps him see the direction what we'd like
the thing to go.
Everybody happy?
On 22.02.2005 18:29:41 Glen Mazza wrote:
> WDYT?
Jeremias Maerki
java.
I don't buy that.
> Note, of course, these aren't vetoes.
A veto would have been easier. :-) I would simply have stopped and said:
"Sigh. Again. Ok, next task."
Would it be more interesting/agreeable if we would leave the render.awt
package and create an AWTRende
On 22.02.2005 12:43:56 Renaud Richardet wrote:
> Mark, just let me know when you'll start to work on it.
> Clay, sorry for not making clear that i needed the maintenance code
> for reference.
> Jeremias, thanks for the pointer
>
> i'm not sure about the following. pl
ges:
- Package org.apache.fop.render.awt becomes org.apache.fop.render.java2d
- AWTRenderer.java becomes Java2DRenderer.java (AWT*.java ->
Java2D*.java)
I think the viewer subpackage can stay as is under the renamed package.
Any objections?
[1] http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec.html
Jeremias Maerki
27;keeps' I believe.
>
> In any case, if you wish to contribute to FOP development, please check
> out the HEAD branch. You may look to fop-0.20.5 for reference, but any
> work you do on that branch will probably not be integrated into FOP
> 1.0.
Jeremias Maerki
Ah yes, that makes sense. Thanks a lot Vincent. I didn't think about
that.
On 21.02.2005 21:54:19 Vincent Hennebert wrote:
> Jeremias Maerki a écrit :
> > Am I right that for a table-cell in collapsing border model the
> > conditional part of a (ex. in border-before-width)
&g
associated edge
is (can be) a leading edge in a reference area from this (table-cell,
table-row, table-body) formatting object". H.
On 21.02.2005 18:11:22 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Am I right that for a table-cell in collapsing border model
>
Am I right that for a table-cell in collapsing border model the
conditional part of a (ex. in border-before-width)
has no effect (i.e. is ignored)?
Thanks,
Jeremias Maerki
Right here: http://nagoya.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=984205
On 21.02.2005 01:15:41 Renaud Richardet wrote:
> Jeremias,
>
> > I went back to Simon's and Finn's ideas about page breaking and I see
> > some overlap.
>
>
to have ignored your
earlier input. I didn't. I appreciate it very much and depend on it.
[1] http://wiki.apache.org/xmlgraphics-fop/TableLayout
Thanks,
Jeremias Maerki
Done.
On 19.02.2005 21:45:28 Thomas DeWeese wrote:
> Hi all,
>
> Can you remove (or comment out) the stray System.out in
> xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java:439
>
> Thanks!
Jeremias Maerki
R-DOC.html (see comment 20)
Wow, now I need a pause.
Thank you, Glen!
Jeremias Maerki
x27;s why the formulas are there to
derive start|end-indent from the corresponding properties. The formula
you're refferring to here is actually used inside IndentPropertyMaker.
It is used to create the "margin-corresponding" value which is used in
the formula sets 1 and 2.
> or zero for the margin properties on fo:region-body.
> (i.e., we just rely on the 50pt. on
> simple-page-master.)
>
> So Luca is correct that both fo:simple-page-masters
> should generate the same overall margins of 50 pt.
> each, no?
No. :-)
Jeremias Maerki
90pt, no less.
On 16.02.2005 05:15:36 Glen Mazza wrote:
> On second thought, Jeremias, instead of arguing this,
> why don't we just compromise at 75pt. margins? ;)
Jeremias Maerki
gt; Properties, 2nd para of 5.1.2, is unfortunately vague
> about which properties are actually CP's.
Jeremias Maerki
rrespond to the various
> absolute "margin" properties."
>
> I'm uncertain that that means that they are
> Corresponding Properties however--I wonder if you are
> reading too much into the word "correspond".
Jeremias Maerki
On 15.02.2005 17:46:54 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > Hi Luca,
> >
> > the reason for the effect you're seeing is the
> > inheritance of
> > start-indent and end-indent. In your exapmle, if you
> &
which
model is used so the painting code knows how to interpret the border
width.
On 15.02.2005 17:41:27 fop-cvs wrote:
>Wiki: XML Graphics - FOP Wiki
>Page: CollapsingBorderModel
>URL: http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel
Jeremias Maerki
computed ipd is right when the margins are set in region-body, but it is 0
> if they are set in simple-page-master, because relDims.ipd is already 100
> and start- end-indent are 50.
>
> As this method has not been modified recently, the error (if this
> behaviour is really wrong) must be elsewhere ...
>
> Regards,
> Luca
>
>
Jeremias Maerki
hat later.
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33555
On 13.02.2005 12:26:27 Simon Pepping wrote:
> Jeremias,
>
> I have looked into the problem in more depth. The wrong retrieved
> marker is not only due to the bogus area, but also to the flawed logic
&g
Thanks, Simon.
And fop-devs, also note that you are allowed (and encouraged) to correct,
modify, improve and add test cases yourself. :-)
On 12.02.2005 14:25:12 Simon Pepping wrote:
> Jeremias,
>
> Note that you can use the ancestor axis:
> xpath="//text[. = 'line1']
yte languages or not?
> If supports, what are the steps i need to follow.
> Where can I get more information about FOP 0.15.
> Please help me in finding the solution for this.
>
> Thanks and Regards,
> Raju
Jeremias Maerki
kPoss() stage. Does anyone know? There are no such
traits described in the spec that I could find in a quick fly-over. And
IMO it doesn't make sense to do it this way. What am I missing?
On 10.02.2005 14:28:45 Jeremias Maerki wrote:
> Ouch! The PageSequenceLayoutManager has a big problem
getNextBreakPoss() on a new page. So it's not
resetPosition() methods that don't behave as I claimed in my earlier CVS
message (although I found a few strange things with resetPosition() while
looking at table headers/footers).
On 10.02.2005 13:52:35 jeremias wrote:
> jeremias2005/0
ite powers. ATM the commits are
going to FOP. The commits list will also receive changes made in the new
SVN repository for the XML Graphics website which I hope will also soon
be created. Please subscribe by sending an empty mail to
[EMAIL PROTECTED]
Jeremias Maerki
lists at the end for all to see.
[ ] Chris Bowditch
[ ] Thomas DeWeese
[ ] Christian Geisert
[ ] Clay Leeds
[ ] Keiron Liddle
[ ] Jeremias Märki
[ ] Glen Mazza
[ ] Simon Pepping
[ ] Jörg Pietschmann
***
Corrected. Thanks, Simon.
On 09.02.2005 22:08:20 Simon Pepping wrote:
> Jeremias,
>
> On Mon, Feb 07, 2005 at 10:29:10AM +0100, Jeremias Maerki wrote:
> > Simon,
> >
> > can you tell me which parser and XSLT processor combination gave you
> > these problems? I&#
Uhm, don't look too closely at my latest test cases. I've made some
mistake in interpretation. Revisiting now...
Jeremias Maerki
ol to
meet some of you there, especially those I haven't met personally or on
the phone yet. Also, it might be a great opportunity for a little
hackathon.
Jeremias Maerki
Simon,
can you tell me which parser and XSLT processor combination gave you
these problems? I'd like to reproduce the problem so I can be sure I fix
them correctly. Thanks.
On 06.02.2005 13:54:54 Simon Pepping wrote:
> Hi Jeremias,
>
> I have errors with the layoutengine test file
le improvements to the code quickly so it
shows to the outside that the project's not dead like many users think.
We'll see what happens. Thanks for your input and I hope you'll find
some time soon to do some coding yourself.
On 06.02.2005 22:08:40 Simon Pepping wrote:
> Jer
method is easily removed if it
turns up later that it can be handled differently and in a better way.
On 06.02.2005 04:43:48 Glen Mazza wrote:
> Jeremias,
>
> I don't see the need for the bBogus variable/isBogus()
> method, because in the three or four places where the
> value
Glen,
no, that's ok. Thanks for the review. I've removed my change locally and
will commit either tomorrow or on Monday. I can't commit right now
because it overlaps with my changes for the marker problem where I still
hope for another comment.
On 05.02.2005 04:11:10 Glen Mazza wr
st: Making an integration of Foray into my JAFOP thingy. I'm quite
interested in comparing FOP 1.0dev with other implementations as I go.
Gotta find some time...
On 04.02.2005 18:04:24 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Chapter 4.2.2 Common Traits defines fou
Well, this might have been a bit premature. The change necessary
actually fixed a bug in AbstractRenderer, but still it might be worth
discussing the point.
On 04.02.2005 15:51:58 Jeremias Maerki wrote:
> Team,
>
> Chapter 4.2.2 Common Traits defines four traits (top-position,
> bot
new reference-area which
establishes a new coordinate system. So I don't think it will be
complicated to calculate the right coordinates. But I may be wrong.
Opinions?
Jeremias Maerki
special areas
are not a big problem since there are relatively few of them.
Still interested in opinions and ideas.... Thanks!
On 03.02.2005 18:19:29 Jeremias Maerki wrote:
> Team,
>
> I've just checked in markers5a and markers5b which look very closely
> which marker is ad
is
generated (empty block with only markers).
You can easily see these bogus areas when you output to the area tree
renderer or in build/test-results/layoutengine when running the Ant
build.
I'll continue investigating but would appreciate any ideas you might
have.
Jeremias Maerki
ncing
> going to be change in the next release to make it work more accurately?
Jeremias Maerki
Good for the next time.
On 02.02.2005 15:24:44 Luca Furini wrote:
>
> Jeremias Maerki wrote:
>
> > If someone has an idea about the ArrayOutOfBoundsException, all the
> > better. I'm currently trying to debug that thing.
>
> It's because of this line in
No, it don't think so. That bug happens in getNextBreakPoss() while mine
happens in addAdreas().
On 02.02.2005 10:36:41 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> > Just to be clear. This ArrayOutOfBoundsException is not the same problem
> > I've described i
feeds displayed as "#". So, this test will fail because of the
single check in the test case.
If someone has an idea about the ArrayOutOfBoundsException, all the
better. I'm currently trying to debug that thing.
On 01.02.2005 22:51:38 jeremias wrote:
> jeremias2005/02/01 1
new MinOptMax(fs.getCharWidth(textArray[iTempStart])));
}
wordIPD.add(MinOptMax.multiply(letterSpaceIPD, (iTempStart -
iThisStart - 1)));
vecAreaInfo.add
Jeremias Maerki
lease send questions to the "fop-user"
mailing list, not to this list which is dedicated to the development of
FOP. Thanks.
On 31.01.2005 09:48:06 jeb501 wrote:
> Anybody there to help me to get start with FOP
Jeremias Maerki
ting
for FOP. They may not be very systematic but they helped me a lot to
identify problems while coding and they make fine regression tests.
I hope if they do write a test suite that it's publicly available from
the start so we can start using it as soon as possible.
Jeremias Maerki
re are any they will surely come up sooner or later.
On 31.01.2005 00:15:19 Glen Mazza wrote:
> Pardon me, forgot to ask: where did the background images need to be
> implemented (i.e., which FO's needed them that the spec doesn't support)?
Jeremias Maerki
bit exotic.
I don't quite see the use-cases for this whole thing yet. But for XSL
1.0 it essentially means that there's only one VPA if the BPD is set,
right? So the current implementation in FOP would be ok for now.
Jeremias Maerki
ort is needed to fit the contents, the keeps, breaks, and spaces would
> be used to decide which content went to an anterior vp and which to a
> posterior vp, just like in any page-break decision.
Hmm, seems like there's some room for interpretation. Yet another
question for the FO WG. Sigh.
I guess we're not so bad off with the current handling, so I'll let it
be for the moment and go on to more important tasks. At any rate, this
thread is flagged in my mail client...
Thanks,
Jeremias Maerki
On 26.01.2005 18:43:58 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Now, I've got a different problem. I run accross a bug in
> > layout concerning block-containers with height/BPD specified
> > (absolute-position="auto"). I tried to fix it but I
Can anyone tell why there was such a layout manager reuse in the first
place? I guess there was a reason.
On 26.01.2005 18:51:55 jeremias wrote:
> jeremias2005/01/26 09:51:55
>
> Modified:src/java/org/apache/fop/layoutmgr
> PageSequenceLayoutManager.
this, but it didn't help.
Any pointers are appreciated.
Jeremias Maerki
; Replaced absolute image paths with relative
Jeremias Maerki
1 - 100 of 1653 matches
Mail list logo
