-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
As for the build targets: so we don't remove these, but it
seems we definitely could/should tweak these to accomodate
the creation of the JAR that will be offered through OFFO,
What I did so far (locally
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Andreas L. Delmelle wrote:
snip/
Have the scripts --.bat and .sh-- append
'${FOP_HOME}/build/fop-hyph.jar' to
the local CLASSPATH. I'm not too sure about the location here:
is 'build'
OK, or should we dump
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
When the jar is built by ant it should end up as
'${FOP_HOME}/build/fop-hyph.jar'. When it is downloaded from
elsewhere, '${FOP_HOME}/lib/fop-hyph.jar' would be a good place. All
jars in lib are added to the classpath
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Yes, that's ok. Just do it (TM). :-) It's only the non-inline level
layout managers that I'd like to put under a certain amount of
protection. Everything else can be changed at will.
Done... well, everything except
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Goo oway and bekome a Teecher.
Yea... To offer an alternative: Glen, translate Jeremias' proposal in both
I know, I know
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
... I'm now calling for a formal vote for a release of our
transcoders. The only thing we do is tag CVS HEAD, ...
(Seems I overlooked this one...)
+1
Cheers,
Andreas
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi,
I see two LM classes that appear misnamed, which can
cause confusion as to their purpose:
1.) FlowLayoutManager is defined as the layout
manager for an fo:flow object -- but actually it can
also be for an
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Hi Luca,
Working on lists, I found a couple of paragraphs in the recommendation
whose meaning is not fully clear to me.
Section 6.8.3. (fo:list-item) states that:
the block-progression-dimension of the
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Andreas L. Delmelle wrote:
IIC, what is meant is:
the space-* of the contained blocks should be seen as _content_
of the list-item, such that they are not ignored, but their
values are _included_ in the total BPD
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
--- Luca Furini [EMAIL PROTECTED] wrote:
My first impression is that I would find somewhat
strange that the *page* breaking is not in the
*Page*SequenceLM! :-)
Well, under our current philosophy, our LM's map
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
Would we need a 'check' on whether the previous page already
contains areas generated by elements of a given BlockSequence
(or: whether the first area on curPage is also the first area
generated
-Original Message-
From: Alex Milowski [mailto:[EMAIL PROTECTED]
Hi,
I've just recently checked out the current CVS tree and built FOP. It
doesn't seem to be handling the break-before/break-after properties with
the
value 'page' at all.
Yep! We're currently working precisely at
-Original Message-
From: Alex Milowski [mailto:[EMAIL PROTECTED]
Hi,
Is there a list of the different code branches somewhere?
One very quick way to get all the branches is ViewCVS:
http://cvs.apache.org/viewcvs.cgi/xml-fop/
Then at the bottom of the page, you have a drop-down
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Hi,
snip /
I don't know if the methods could be moved to the FLM: besides the break
value, they depend on the current page number and this is known only by
the PageSequenceLM.
Yeah, it was just a thought... I assumed
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
(Apologies in advance if the post seems a bit long; really don't mean to
bore you ;-) )
snip /
With an FLM-centric approach, what I'm seeing is
something like either of these two: (pseudocode)
a) Within
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
snip /
I was thinking of the FLM controlling layout for *all*
the FO descendants of the fo:flow. One and only one
FLM instance for the fo:flow of an fo:page-sequence.
OK, clear now and fully agreed on this.
It returns
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
--- [EMAIL PROTECTED] wrote:
-protected void startPart(BlockSequence list)
{
+protected void startPart(BlockSequence list,
int localPageNumber) {
boolean isFirstPageByBlock is probably better.
The
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Jeremias Maerki wrote:
I'm a bit concerned about the increasing complexity of this. It takes
considerable time just to understand and play through all these examples
and after that implementing it so that the code
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
snip /
BTW: Am I the only one who has trouble viewing the pictures on the wiki
page? (It seems to be the only one with which I have problems. The other
table-related pages show up nicely...)
That also means that
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
I've attached the picture and an FO file I wrote today to mimic that
picture.
Apologies. Damn *me* now for not having tried this with a decent browser...
of course IE will let you down.
More feedback probably
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
On 27.04.2005 18:28:55 Andreas L. Delmelle wrote:
snip /
BTW: Does this problem pose itself only if a single cell
or row spans more than two pages, or also when an entire
row-group does so?
Possibly, yes. A row
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi,
The AbstractBreaker.BlockSequence has an iStartOn property, that from
looking at PSLM, quite possibly just means the break-before trait.
Are they synonyms?
Not really. I seem to agree with Jeremias here, in that
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
Hi Simon,
At first sight I agree with Andreas' interpretation in his reply to
this message, which I think is the same as your original
interpretation. Thinking on, however, I see that there may be a
problem with
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
Let me have a go...
Glen Mazza wrote:
Kein Problem. Bald werde ich dass machen, aber nicht
dieser Nacht, weil ich ziemlich muede bin.
No prob. I'll do it soon, but not tonight, because I'm quite
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Glen:
Ja, jetzt sollen wir das alterer Kodierung
(pNFA() usw.) entfernen. ...
English: Yes, we should remove the old code now.
Of course 'should', got my modal verbs mixed up again :-)
Greetz,
Andreas
-Original Message-
From: Jerry [mailto:[EMAIL PROTECTED]
Hi,
Would you please remove my email from this list?
because I am not actively participate in this forum.
An empty message to '[EMAIL PROTECTED]' should do
it...
Cheers,
AD
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi,
i've downloaded the FOP-Sources 0.20.5. But it seems, that some Java-Files
are not included e.g. within the package org.apache.fop.fo.properties.
Am i right?
Yes... and no --seems to become one of my favourite
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
On 10.05.2005 20:41:19 Simon Pepping wrote:
Hi guys,
For starters: my vote is +1.
I agree with Simon, and also very much feel like we're on the right track
with this. Sure, it will *still* take some work...
snip /
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Hi Luca,
First of all: compliments on yet another Nice Job!
At the moment the page breaking algorithm is quite strict: it tries to
insert every footnote in the same page where their citation is (the last
footnote body
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi Jeremias and others interested in table-borders,
(Sorry for the --again-- long post, but...)
The following comment in the code (TCLM) got me wondering...
//Create empty grid units to hold resolved borders of
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
(OK, apologies for my alias turning up... Completely unintended.
here's the remainder of the response. Other comments, much longer than the
previous one...)
On 17.05.2005 23:24:55 Andreas L. Delmelle wrote
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
Did a simple 'svn co' and subsequent build: zero problems here. Saw Simon
correctly being mentioned as the last author.
But...
Please verify that everything is as expected by checking out your project
from SVN.
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
snip /
Another option: validateChildNode() is called from only one place,
FOTreeBuilder.startElement(). At that point, we can also feed vcN() the
parameter namespaceURI.intern() instead of just namespaceURI.
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
Glen is right. java.lang.String.equals() checks == as the first
statement. So this change shouldn't have a big impact on performance. It'
just an additional method call (which might even be inlined by the JIT).
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
... So I believe Nils proposed change doesn't have
any negative effects, especially since we don't seem to have pursued a
more widespread use of String.intern() back when it was discussed in
December 2003
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
snip /
Oh no, it wasn't--but we know the status quo *wasn't* acceptable, and
that the performance argument was no longer valid because of the
research you did on .equals(). Now you and Andreas can finish out the
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
But since == *is* faster then .equals and I think we can assume that
most URIs are in fact from the FO namespace we can get the benefit from
both.
Measured with jdk1.4.2_02 on winXP:
Equal string
== 141
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
But since == *is* faster then .equals and I think we can assume that
most URIs are in fact from the FO namespace we can get
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting conceptual question. Please have a look at the attached
test
case. It defines a table with two columns and two rows. In the given
setup the second row
Sorry, forgot the attachment...
table-body4b.xml.head.pdf
Description: Adobe PDF document
On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote:
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting
On Jul 28, 2005, at 10:10, Jeremias Maerki wrote:
On 27.07.2005 23:26:48 Andreas L Delmelle wrote:
Indeed, doesn't look right. Given the value for the orphans property,
one still would reasonably expect the break to occur before the first
cell of the second row.
...or after the first 3 lines
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 29, 2005, at 23:25, Jeremias Maerki wrote:
Strike that. Just found a mean case where my quick hack breaks. Back to
frame one and a half. It's going to be a bit more difficult.
FWIW: It occurred to me that, with a break-before=page on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 30, 2005, at 11:51, Jeremias Maerki wrote:
D'oh, right. :-) Lucky me.
Too bad, we don't generate validation warnings for misplaced
non-inherited properties. Didn't we have that discussion already this
year? I can't find it or am I imagining
On Jul 30, 2005, at 17:34, Manuel Mall wrote (on bugzilla):
Manuel,
Devs,
To be able to simply replace a 0.20.5 fop.jar with 1.0dev fop.jar I
have written
a backwards compatible apps.Driver.java class. Everything in the class
has been
labelled as deprecated.
FWIW: Personally, besides the
On Aug 1, 2005, at 11:37, Manuel Mall wrote:
no argument from me against what you are proposing and also Joerg in
[1]. We
can still have a Driver.java for backwards compatibility for those who
want
to plug and play either in the product, or in a separate jar
(fop-compat.jar?), or just here in
Merely FYI: slight correction needed...
On 30.07.2005 15:14:04 Andreas L Delmelle wrote:
Currently, I don't think we already have a mapping of these
object-applicable_props anywhere, ...
We do have such a map in org.apache.fop.fo.PropertySets, but I don't
get the impression
On Aug 1, 2005, at 18:57, Sergey Simonchik wrote:
Hi,
Currently I work on upgrading FOP's RTF rendering. We need it as a
part of another project.
And now some patches to RTF-rendering with test cases are available.
So I have two questions:
1) Would you be so kind to tell your intention about
On Aug 2, 2005, at 11:14, Jeremias Maerki wrote:
On 01.08.2005 18:31:35 Andreas L Delmelle wrote:
... Right now, the Driver would have to be wrapped around
the main-class, which is something I do NOT like :-/
I doesn't have to. The Fop class is so light-weight (if you think the
main
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 23, 2005, at 22:09, Finn Bock wrote:
Andreas L Delmelle wrote:
The type should be a number with added 'force' enum. The number
property will then coerce a 'force' value into an EnumNumber which is
a number that also holds a enum value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 23, 2005, at 23:32, Andreas L Delmelle wrote:
On Aug 23, 2005, at 22:09, Finn Bock wrote:
So if it is possible at all, I would prefer to see that the
inheritance issues is implemented in the PropertyMaker classes,
instead of the FObjs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 24, 2005, at 19:15, Andreas L Delmelle wrote:
Wouldn't inheritance still work as desired --by the Property
subsystem-- if the default value is set in the FObj's bind() method?
Hmm. ATM, it doesn't seem to be working...
I tried using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Has anyone ever thought about introducing an abstract class for
table-related FOs, say TableFObj, that would be extended by all those
FOs?
It just occurred to me that there are:
a) the border-precedences that are applicable only to those
On Aug 27, 2005, at 09:09, Jeremias Maerki wrote:
Ok, the shock is gone. Thank you for reassuring me that you know what
you do. That was my biggest concern. I'm happy that you can reuse some
of my code. Finally, someone can use something I wrote to make better
progress. Normally, it's the other
On Aug 27, 2005, at 22:22, Jeremias Maerki wrote:
On 27.08.2005 21:33:44 Andreas L Delmelle wrote:
I'm wondering, for instance, whether the table's before-border specs
are only relevant for the first page that is spanned by the table. For
example: in case the table has a header (and
omit
On Aug 28, 2005, at 04:33, Manuel Mall wrote:
I must admit I know very little about collapsing borders. Therefore if
my comment is useless just ignore it.
Well, I certainly don't think it's useless...
I have recently worked on all this percentage stuff. This applies
also
to border-width
On Aug 28, 2005, at 14:38, Andreas L Delmelle wrote:
On Aug 28, 2005, at 00:06, Jeremias Maerki wrote:
AFAIK you're trying to move the pre-resolvable pieces into the FO
tree while you only do the
specialities in the LMs, right?
Exactly. Come to think of it, maybe that last idea won't
On Aug 28, 2005, at 15:57, Manuel Mall wrote:
This is just a clarification question to those in the know.
In HTML when specifying a table browsers usually choose the smallest
width without causing unforced breaks in columns. That is in XSL-FO
terms the ipd of the table can be smaller than the
On Aug 28, 2005, at 16:21, Manuel Mall wrote:
[Me:]
We could either:
- drop the table completely (+ warn about this, of course)
- explicitly notify the user that, because auto-layout is not
supported, the default value of auto is ignored and replaced by
100%
I second that for the time being.
On Sep 2, 2005, at 18:42, Vincent Hennebert wrote:
Hi Vincent,
You're right. Indeed both situations below are handled by the
standard, thanks to border conditionality and is-first/is-last traits.
Thanks for the pointer!
You're welcome, of course.
I have to correct myself on the following,
On Sep 5, 2005, at 10:29, Jeremias Maerki wrote:
Manuel Mall ...
That's why I'd like to nominate him for
committership in Apache FOP.
Definitely a BIG +1 from me.
Cheers,
Andreas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
In my attempt to facilitate an implementation of the collapsing border
model on tables by moving the lion's share of the logic from
layoutmgr.table over to the fo.flow package, I stumbled upon some other
parts that are currently dealt
On Sep 11, 2005, at 11:52, Jeremias Maerki wrote:
Hi,
On 10.09.2005 01:41:05 Andreas L Delmelle wrote:
This kind of on-the-fly normalization of the tree structure has
advantages for layout in that the table-grid co-ordinates will be
readily available (no interpretation needed, just pick up
Hi,
The Rec describes the default value for the column-number on
table-cells as:
For the first table-cell in a table-row, the current column number is
1...
My question: is this also true in case there was a row-spanning cell
from the previous row that already occupies the first column? IOW:
On Sep 12, 2005, at 11:49, Jeremias Maerki wrote:
The current code works that way. The first free grid unit is used.
OK. Thanks for the confirmation.
FYI: I'm currently almost done with having the initial values set by
the Property subsystem itself. (Finn's recent addition of
On Sep 12, 2005, at 12:06, Jeremias Maerki wrote:
Uhm, given that we've decided to remove the hyphenation patterns
entirely, we can't do these tests at all. D'oh!
BTW: On the release-plan Wiki, I noticed that the hyphenation patterns
still haven't been removed yet. I remember running into
On Sep 12, 2005, at 12:48, Manuel Mall wrote:
On Mon, 12 Sep 2005 06:17 pm, Andreas L Delmelle wrote:
BTW: On the release-plan Wiki, I noticed that the hyphenation
patterns still haven't been removed yet. I remember running into
problems while trying to remove them a couple of months ago, so
On Sep 12, 2005, at 12:01, Andreas L Delmelle wrote:
FYI: I'm currently almost done with having the initial values set by
the Property subsystem itself. (Finn's recent addition of
TableBorderPrecedence gave me just the hint I needed to get the
necessary understanding of the property system
Hi,
I can describe the case only, since I can't commit my changes yet (they
still break a few layout tests), so please ask further if you don't
have enough info to form an idea of my changes.
Maybe better to wait to when I commit my stuff to a branch --tomorrow
or Thursday--, so you get a
On Sep 13, 2005, at 19:58, [EMAIL PROTECTED] wrote:
Author: bckfnn
Date: Tue Sep 13 10:57:58 2005
New Revision: 280608
URL: http://svn.apache.org/viewcvs?rev=280608view=rev
Log:
Run the checks on the parent's propertyList.
OK, so it wasn't me after all... :-)
Thanks a lot for the very quick
On Sep 13, 2005, at 22:06, Finn Bock wrote:
[Andreas]
Very roughly, the new ColumnNumberProperty.make() does something like
this:
That should be ColumnNumberPropertyMaker in order to follow the naming
of all the other custom makers.
OK, I'll keep that in mind... Shouldn't it be
Hi people,
Just finished implementing the initial values for the column-number
property.
(Subversion still complains about files remaining in conflict, though,
so I'll have to check those out first. Have to go now, but commit will
most likely follow tonight...)
All layout tests passed
On Sep 15, 2005, at 13:50, Jeremias Maerki wrote:
snip /
But it should be clear that an explicitely defined property should
override the default on the other corresponding property.
Hmmm... 'should be clear'? No offence, but that is interpretation, not
fact.
The term 'corresponding
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
Jeremias,
Ok, let me then explicitely state that my previous mail contained my
own
interpretation and no facts. IMO there are certain gaps and
inaccuracies
in the spec and I tried to take my own expectations and create an
interpretation that
On Sep 16, 2005, at 12:15, Jeremias Maerki wrote:
Absolutely no resentment here. I'm sorry for sending the wrong signals.
I simply realized that I was not clear enough that the stuff I wrote is
just my opinion. Stuff like that always happens if I don't want to lose
too much time. Sigh.
Ok,
On Sep 16, 2005, at 12:26, Finn Bock wrote:
My take is that only a true value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
false or an explicit false is found.
FWIW: That was precisely my understanding too, hence my speaking of a
On Sep 16, 2005, at 16:00, Andreas L Delmelle wrote:
Well, currently you both got me convinced about this. I'm working on
it --but a bit frustrated, since that was really the *only* case where
it failed. All other situations are handled nicely including
row-spans... --even when a user would
On Sep 16, 2005, at 16:31, Andreas L Delmelle wrote:
YES! Got it.
Ok, so I ended up thoroughly revising my approach, to account for the
starts-row/ends-row issue that was the topic of this thread.
One thing I also hadn't considered, but which I also succeeded in
dealing with now, is out
On Sep 18, 2005, at 21:58, Finn Bock wrote:
Hi Finn,
+if( pList.getExplicit(PR_COLUMN_NUMBER) != null ) {
+((TableFObj) parent).setCurrentColumnIndex(
+
pList.getExplicit(PR_COLUMN_NUMBER).getNumeric().getValue());
+}
Why is explit specified
On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:
Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!
Dammit! And I thought I had all bases covered... :-(
My apologies for
On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:
On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:
Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!
Dammit! And I
On Sep 20, 2005, at 17:40, Matthew L Daniel wrote:
Hi Matthew,
The least this would do is avoid a number of unnecessary calls to
instanceof.
You're on the right track, and maybe that switch impl would be an
80/20 win over the cost of the Right Way. But that huge if-instance
case
is exactly
Hi,
Jeremias, Luca or Simon will probably be able to make the most sense
out of it, but if there's anyone else that can add a few comments, feel
free to do so.
(FYI: This is completely separate from my idea to move the
border-collapsing to the FOTree.)
Now, I'm still not fully at home in
On Sep 21, 2005, at 18:26, [EMAIL PROTECTED] wrote:
A question for Finn, I presume...
Author: adelmelle
Date: Wed Sep 21 09:25:57 2005
New Revision: 290736
URL: http://svn.apache.org/viewcvs?rev=290736view=rev
Log:
Added fallback for specified negative or zero for column-number
As you see,
Hi,
I took a quick stroll through the code, and now I'm really getting the
impression that implementing indefinite page-width or page-height isn't
all that hard to achieve.
(Those enlightenments by Jeremias and Manuel yesterday sure gave me the
kick that was needed to grasp what happens and
Hi,
A question: I noticed that the warning about tables having padding and
border-collapse=collapse has been commented out recently, since
hasPadding() now requires context.
Can anyone explain why precisely this was done? IOW: why does a
PercentBaseContext *always* need to be provided? Why
Hi,
Another question related to page-height and page-width properties on
simple-page-master:
The Rec states that, in case the value is specified as auto:
The 'page-height/-width' shall be determined, in the case of
continuous media, from the size of the User Agent window, otherwise
from the
Hi,
(Apologies for the many posts... I'm definitely on a roll :-))
Now that it has been made clear to me that the layout-engine first
calculates *all* break-possibilities, IMO this also seems to make
implementing page-position=last much, much easier.
Assuming that no areas are generated
On Sep 23, 2005, at 18:12, Andreas L Delmelle wrote:
snip /
It almost makes it seem as if padding always needs to be specified as
a percentage-width, or somehow a fixed-length is always interpreted as
the specified fixed-length * 100%...?
Or, more correctly: as if the fixed-length
On Sep 23, 2005, at 18:32, Andreas L Delmelle wrote:
Now, I was thinking, since currently the fallback values are used as
defaults --which, strictly speaking, is wrong-- maybe the first step
towards implementing auto could be to define these fallbacks in
fop.xconf (?)
Duh! I mean, we
On Sep 24, 2005, at 03:36, Manuel Mall wrote:
snip /
Thanks for the info Manuel.
Cheers,
Andreas
On Sep 24, 2005, at 17:22, Manuel Mall wrote:
On Sat, 24 Sep 2005 11:04 pm, Andreas L Delmelle wrote:
It seems then that the vertical-align on the innermost inline
actually refers to the after-edge, which IIC would be relative to the
after-edge of its parent (and not that of the block ancestor
On Sep 24, 2005, at 17:39, Manuel Mall wrote:
On Sat, 24 Sep 2005 11:27 pm, Andreas L Delmelle wrote:
Anyway, the full description would be:
The alignment-baseline on the first inline is aligned with the
before-edge baseline of the outer block. Now, IIC, this has an impact
on its own after
On Sep 24, 2005, at 17:05, Manuel Mall wrote:
Hi Manuel,
I just discovered something unusual in the spec. It describes the
dominant-baseline property in a number of places as:
'The dominant-baseline property is a compound value with three
components.'
It then goes on and lists the 3 components
On Sep 24, 2005, at 19:09, Andreas L Delmelle wrote:
As to how to integrate this: no clear idea ATM, but I'll give it some
thought.
Maybe Finn or others have a few ideas to add?
On second thought, maybe all you really need is to subclass
EnumProperty to DominantBaselineProperty, and give
On Sep 25, 2005, at 12:16, Andreas L Delmelle wrote:
On Sep 25, 2005, at 05:19, Manuel Mall wrote:
Hmm, not sure about this one. The actual rules for computing his
compound value are actually a bit involved and require information
possibly not readily available to the property system.
Aha
On Sep 22, 2005, at 23:28, Andreas L Delmelle wrote:
Hi all,
This post as a status-update, since I've been playing around with this
during the weekend:
snip /
I'm definitely going to take a closer look soon, but right now I'll
just add a few comments for future reference (in case I don't
On Sep 26, 2005, at 16:03, Jeremias Maerki wrote:
It's an interesting idea. However, I suspect this will probably not be
necessary. We should be able to make the breaker clever enough to
handle
this particular case. ATM, I don't have free brain capacity to dive
into
this (even though this is
On Sep 26, 2005, at 07:01, Manuel Mall wrote:
On Mon, 26 Sep 2005 05:25 am, Andreas L Delmelle wrote:
BTW, stumbled upon an interesting issue:
Does anyone know how percentages should be viewed in case the page's
height is indefinite? Or would this simply be something the user
shouldn't
On Sep 26, 2005, at 18:26, [EMAIL PROTECTED] wrote:
snip /
[EMAIL PROTECTED] changed:
What|Removed |Added
---
-
Status|NEW |RESOLVED
On Sep 27, 2005, at 14:34, Manuel Mall wrote:
Hi Manuel,
what to you make out of the following?
In 7.13.2 alignment-baseline is defined as having the values:
auto | baseline | before-edge | text-before-edge | middle | central |
after-edge | text-after-edge | ideographic | alphabetic | hanging
1 - 100 of 661 matches
Mail list logo
