Sounds reasonable to me--I think I should have done the validation that
way to begin with (IIRC =='s are Not Good with Strings anyway for the
very reason you gave.) I am surprised this problem did not occur
before. I'll make the change next.
I am personally pleased that FOP 1.0 is now
Andreas L. Delmelle wrote:
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Committers, I don't see a problem with what Nils proposes. Does anyone
else? If not, I can do the change next week. If Nils already has a patch
for us, even better. :-)
Well, the whole
Jeremias Maerki escribió:
On 26.06.2005 14:41:13 Glen Mazza wrote:
snip/
Well, the whole idea behind using interned strings and the == operator is
speed.
As you both are probably well aware, using .equals() on interned strings is
a lot slower than comparing them
The recommendation allows any property to be on any FO (First sentence
of section 5 of 1.1[1], but also somewhere in 1.0), regardless of its
utility. So we don't need to mention this as a warning.
We *might* want to do this in a few areas though where newbies might
make very common mistakes
Peter B. West wrote:
You can always get the sources using the official command-line client
that comes with Subversion:
http://subversion.tigris.org/
http://subversion.tigris.org/project_packages.html
Which is what I had to do with BitKeeper, for which no client existed in
NetBeans,
Jeremias/Another committer,
For SVN access, I'm trying to use TortoiseSVN right now. (I can log
into svn.apache.org using Putty without problem.) Also, I can easily
check out FOP -- but it seems to be checking out the files as
anonymous because I can't make any commits using Tortoise (I get
Cool! https:// did it! Thanks, Clay (and also Jeremias for taking the
time to give all the links)--this is so much fun, I think I'll finish up
FOP tonight... ;-)
Glen
[EMAIL PROTECTED] escribió:
Author: gmazza
Date: Thu Jun 23 21:13:43 2005
New Revision: 201562
URL:
Jeremias Maerki wrote:
Ideally, a font engine that is shared between two projects should be in
a more or less neutral place write-accessible by both parties but as
we've seen now there are personal dissonances.
I think Victor said he didn't want to collaborate anymore:
Thanks for the helping our project Richard! FOP/XSL is a fascinating
mathematical equation, and the clearer and rawer we can make that
equation, the more it will attract the best computer scientists and
mathematicians from around the world to help us work on determining it.
Reading your
Team,
This issue is somewhat messy because it involves two parts--but I'll try
to keep it succinct:
1.) The connections between PSLM and
AbstractLayoutManager/LayoutManager have been so reduced that it would
appear now to be a simpler and more robust design to make PSLM
standalone (i.e.,
- Original Message -
But since the PageSequenceMaster is a
stateful beast that can currently only iterate in one direction I'm in
trouble. Next week I'll research a good way to reset or run backwards
the PageSequenceMaster so the already created PV in the Provider can
ultimately be
Luca,
Are you sure here? We had two versions of addALetterSpaceTo() -- the
version in ILLM which takes a List (I didn't touch that one), and a old (?)
version from AbstractLayoutManager that takes a KnuthElement. It is that
latter version that I removed--it wasn't being called anywhere--not the
- Original Message -
I find it strange, Glen, that you dont care whether people use FOP or not.
I'm such a monster.
You
have worked hard on FOP over the last couple of years. Wouldnt you be
disappointed if your work benefitted no one?
Chris
My goals on FOP are to make XSL as
Jeremias Maerki wrote:
Given that the EOL phase for 1.3.1 ends March 2006 [1][2] and given
FOP's estimated time for the next serious release JDK 1.3 compatibility
may really be no big concern. But I know that many people (mostly
running server applications) are still stuck with JDK 1.3 we would
Jeremias, perhaps Luca:
Is there a reason why we maintain separate getNextKnuthElement() methods
within both an LayoutManager and its inner AbstractBreaker? Can they be
consolidated into LayoutManager and we call
getTopLevelLM().getNextKnuthElement() instead within the breaker code?
Three
it in the higher, root-level processing class
here. Thoughts?
Thanks,
Glen
Glen Mazza wrote:
Jeremias, I think we do something like this for ID's already -- I
wonder if we can use a similar approach here.
We already have a PSLM.getFirstPVWithID() method, which due to the
(Map/List) data structure
Jeremias Maerki wrote:
AbstractBreaker has maybe two or three methods in common with
LayoutManager. Furthermore, I see the Breaker as something else than a
layout manager. I think it would be confusing to merge the two concepts.
The duplicate methods can probably be moved up to the base class.
Jeremias Maerki wrote:
I admit that the AbstractBreaker was simply an artifact from merging in
Luca's initial code and which later evolved a bit but I began to like
the distinction between the LMs and the breakers.
OK, we'll keep that distinction then. This would have been a very
trying again...
Original-Nachricht
Betreff:Layout simplifications
Datum: Mon, 16 May 2005 18:14:52 -0400
Von:Glen Mazza [EMAIL PROTECTED]
An: fop-dev@xmlgraphics.apache.org
Team,
Currently the LM classes that use the Knuth breaking strategy employ the
breaking
Team,
Currently the LM classes that use the Knuth breaking strategy employ the
breaking via a nested (inner) class --
PageSequenceLayoutManager.PageBreaker, for example. This is causing
some duplication in methods (getNextKnuthElements(), for example) and
variables in each of the Breaker
Thanks for taking the time to do this analysis. I was wondering where
we were standing on performance.
I think it is clear from the 12sec-7.8 sec drop that keeping
logging/stdout output reduced helps performance. Keeping quiet seems to
be Xalan's approach as well.
I looked at our
[EMAIL PROTECTED] wrote:
jeremias2005/05/12 07:13:45
Modified:src/java/org/apache/fop/layoutmgr/table Tag:
Temp_KnuthStylePageBreaking TableStepper.java
TableContentLayoutManager.java EffRow.java
Log:
Fix for ArrayIndexOutOfBoundsException
[EMAIL PROTECTED] schrieb:
gmazza 2005/05/12 17:54:14
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking
PageSequenceLayoutManager.java
Log:
Copied the logic over incorrectly--fixed (even though IIRC
Excellent!!! Thanks Hank!
FYI Team -- Our MARC Archives[1] are back and have
been populated with the previous months' emails!
Glen
[1] http://marc.theaimsgroup.com/?w=2
--- Hank Leininger [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 22 Apr 2005, Glen
Andreas L. Delmelle wrote:
A closer look at ATH and PV shows that the two above steps are:
- add the unresolved area to the viewport
stored in the VP as a Map id-List
where the List contains references to the source
areas (the link's hotspot, the page-number-citation...)
- add the unresolved
Jeremias Maerki wrote:
Glen,
I'd like you to revert that one and take a different approach if any.
Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil
ich ziemlich muede bin.
handleBreak does really handle break-before AND break-after, so the name
was ok.
Ja, Sie haben
property. It simply indicates
for a BlockSequence on what kind of page it should start after
normalizing where the value originally came from (break-after or
break-before). IMO using break-before here would actually be confusing
and startOn is more descriptive.
On 05.05.2005 06:00:56 Glen Mazza wrote
Team,
The AbstractBreaker.BlockSequence has an iStartOn property, that from
looking at PSLM, quite possibly just means the break-before trait.
Are they synonyms? I would like us to use the official Rec term if at
all possible.
Thanks,
Glen
public class BlockSequence extends KnuthSequence
BTW, is the page breaking also using Knuth's algorithms, or is it from
the research paper* that Jeremias ordered a few months back and was
mentioning to us? I have been generically calling both the line- and
page-breaking the Knuth code--I don't know how correct that is.
Thanks,
Glen
* Also,
Gaywood, Mark wrote:
Dear all,
With your planned release of version 1, is there a list of
anticipated conformance to 1.1 of the XSL:FO specifications?
i.e. What you will and will not be supporting.
Best regards and thank you in advance,
Mark Gaywood
Looks good!
Glen
[EMAIL PROTECTED] wrote:
lfurini 2005/04/27 08:59:59
Modified:src/java/org/apache/fop/layoutmgr Tag:
Temp_KnuthStylePageBreaking AbstractBreaker.java
PageSequenceLayoutManager.java
Log:
Using a more clear boolean instead of
Oops...
--- Glen Mazza [EMAIL PROTECTED] wrote:
--- [EMAIL PROTECTED] wrote:
-protected void startPart(BlockSequence
list)
{
+protected void startPart(BlockSequence
list,
int localPageNumber) {
boolean isFirstPageByBlock is probably better.
The meaning
Did you also request the same from Eyebrowse? I can
do so again if it would help.
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I did on 2005-03-04 and got no response. Thanks for
retrying.
On 24.04.2005 23:43:05 Glen Mazza wrote:
I don't know if someone else has done so earlier
(I
Hi Andreas:
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
[Glen:]
With an FLM-centric approach, what I'm seeing is
something like either of these two: (pseudocode)
a) Within PSLM:
FlowLayoutManager flm = new
FlowLayoutManager(simplePageMaster);
while (pv =
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Indeed not. The FlowLM should definitely keep track
of this, when
applicable --in my description: the FlowLM would
store the reference to its
last processed descendant before the page overflow,
and the PageSequenceLM,
upon finishing one
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Hmm.. This does seem to be one of those situations
where the logic could be
placed anywhere. However, taking into account Luca's
remarks, I would be
inclined to see it as:
The PSLM creates the page-viewports, and passes
them on to
1.
I don't know if someone else has done so earlier (I
recall Chris raising the issue a few weeks back), but
I sent an email yesterday to the MARC list[1] asking
them to switch their FOP lists to our new @xmlgraphics
addresses. I hope they will do so--our present
archives lists aren't very
--- Luca Furini [EMAIL PROTECTED] wrote:
Break conditions in page breaking are quite similar
to preserved linefeeds
in line breaking: they divide a fo:page-sequence in
smaller sequences,
Another way of thinking about it would be that the
array of page-viewport-areas returned by this FO is
Just so I understand how this is supposed to work,
will someone please confirm my assumptions below:
1.) If FOP is processing a block on the middle of page
17 with a break-before value of even-page, FOP is
supposed to render this block at the top of page 18
instead.
and
2.) If FOP is processing
Also, as food for thought, I wonder if the two methods
Luca has mentioned should eventually be in
FlowLayoutManager (FLM) instead. The break properties
appear relevant only for fo:flow descendants.
Glen
--- Glen Mazza [EMAIL PROTECTED] wrote:
Just so I understand how this is supposed to work
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
Also, as food for thought, I wonder if the two
methods
Luca has mentioned should eventually be in
FlowLayoutManager (FLM) instead. The break
Team,
I would like to tighten up the PSLM a little bit
more--namely, I'm inclined to have PSLM stop extending
AbstractLayoutManager or even implementing the
LayoutManager interface. With this change, PSLM will
no longer need to have unused empty methods within it,
and will be as robust,
Hi Luca,
1.) Can the corresponding setting of these values on
fo:root (642-643 of [1]) in PSLM now be removed? (I
think so...because what is set on fo:flow will be used
instead of fo:root.)
2.) Also, does your change below need to be added to
StaticContentLayoutManager as well?
Many thanks,
Jeremias,
I do not fully understand the business logic for
tables--so what I am saying here may not be relevant.
But if cell should *never* be null (i.e., the caller
of this method is very sloppily written), please let
the methods NPE, raise IndexOutOfBoundsError,
InvalidStateException, etc., so
Oops, make that three differences: their content
models (child FO's that the spec says they can have)
are slightly different.
Glen
--- Glen Mazza [EMAIL PROTECTED] wrote:
--- The Web Maestro [EMAIL PROTECTED]
wrote:
or something. That way, it's all in one (since it
can apparently
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Sorry to be such a nitpick, but the 1.0 Rec. states
literally:
An fo:marker is only permitted as the descendant of
an fo:flow.
and
An fo:retrieve-marker is only permitted as the
descendant of an
fo:static-content.
Thanks for the
+1
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
+1 from me. The code has been stable over the last
few months and seems
to work well for most cases. I also don't see any
other open issues
preventing a release.
On 25.03.2005 10:39:48 Jeremias Maerki wrote:
Batik is currently preparing
47 matches
Mail list logo
