--- Additional Comments From [EMAIL PROTECTED] 2005-08-05 12:13 ---
Thanks for doing this. Your patch looks good and appears to work.
However, theres one little thing thats puzzling me. Finn, who is our
properties guru wrote the class CommonFont. If you look at the method
getFontState
Andreas L Delmelle wrote:
Hi all,
Back from holiday, and just started work on the collapsing border model
(something I discussed thoroughly with Jeremias a while ago --don't
worry, I'm not going to start all over :-) ) Let me just say that, where
earlier on I didn't have a clear idea on
[Jeremias Maerki]
Looks like you made a thorough analysis. What I read made sense to me
although I didn't check everything to the last character. Providing
the Context interface through the LayoutContext didn't occur to me
and I don't know if it's the right way, but if it just clicks in
there
Manuel Mall wrote:
The safety check in addBackground is already there. This is how I
stumbled across it as it is triggered by one of the layout engine
tests.
Also note that the percentage handling in addBackground is a rough hack
that doesn't work when expressions are used: 40% + 1pt.
[Jeremias Maerki on ]
Yeah: Wow! Finn, you're the specialist here. Can you take the lead on
this one?
I'm hardly a specialist on the layout system, and that is where a good
sized part of Manuels patch is, but in the property system I do not like
the hack to LineHeightPropertyMaker and
[Jeremias Maerki]
Perfect, Finn! I've just hacked together a little test extension that
lets me evaluate properties and write failure messages to a singleton
which a JUnit test case could process. It's very rough right now, but
with a little more work this could really be cool for checking the
[Manuel]
Agree, and I have a solution for that ready to go.
I think this deserves some further comment / discussion. One, IMO
important, reason I want to do the evaluation during the FO parsing
stage is that once we are in the LMs we lost the property inheritance
information. That is
[EMAIL PROTECTED] wrote:
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java?rev=264863r1=264862r2=264863view=diff
[EMAIL PROTECTED] wrote:
+
+ private static void attrBaseLineShift(EnumLength baselineShift, RtfAttributes rtfAttr) {
+
+ String s = baselineShift.getString();
Use baselineShift.getEnum() to get the enum values that is assigned to a
length. Never ever use the getString()
[Jeremias]
No surprise, actually. The tables all use the collapsing border model.
But tell me, have they updated the NIST test suite for XSL Rec 1.0? I
remember that at a stand-still in working-draft stage (master-name
instead of master-reference).
Years back, when we last talked about the
[Luca]
Speaking of extensions, I'd like to resurrect the layout extensions
That isn't exactly use of the term extension which I'm using and which
I think Jeremias is using in the ExtensionPoints wiki. Your extensions
are additional useful features, when I talk about extensions it is the
[Jeremias]
Manuel Mall has been investing a tremendous amount of time and effort
into making FOP better lately. The results were just great. It's been a
pleasure to apply his patches, even though it ate up a lot of my time.
;-) Manuel has been around since at least late 2002, even submitted a
[Manuel]
Is the following legal:?
fo:inline
border=solid 1pt red
border-start-width.conditionality=retain
border-end-width.conditionality=retain
padding=1pt
padding-start.conditionality=retain
padding-end.conditionality=retain
What seems to happen is that for borders it works
[Manuel]
fo:inline
border=solid 1pt red
border-left-width.conditionality=retain
border-right-width.conditionality=retain
padding=1pt
padding-left.conditionality=retain
padding-right.conditionality=retain
I must still be misunderstanding something. The above property
definition
[Manuel]
Inline areas have their own line-height trait which can be different to
the line-height on the containing line area / containing block.
line-height when specified on an inline fo has a different meaning,
i.e. the inline area returned MUST have the exact line-height as
specified,
[Manuel]
Any way, back to the topic at hand. Lets assume the following fo:
fo:blockfo:inline font-size=10ptsome 10pt textfo:inline
font-size=12ptsome 12 pt text/fo:inlinemore 10pt
text/fo:inline/fo:block
In this case the line-height everywhere is normal which is equivalent to
1.2em. The
[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.
regards,
finn
linearea bpd=11100 space-before=1650 space-after=1650
inlinearea bpd=9250
textarea font-size=10ptsome 10pt text/textarea
inlinearea bpd=11100
textarea font-size=12ptsome 12pt text/textarea
/inlinearea
textarea font-size=10ptmore 10pt text/textarea
/inlinearea
linearea
[Manuel]
I am currently looking at adding the missing background and
border/padding support to fo:character and have run into a co-ordinate
system issue. In fop text areas and character areas are positioned in
the bpd direction using the offset attribute which refers to the
character
[Jeremias and Andreas on starts-row ends-row]
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.
[7.26.15]
The starts-row and ends-row properties with a true value are
[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 as
dominant-baseline-identifier, baseline-table
[Peter]
I noticed that you extracted numeric function methods as statics into a
class of their own. Was this for aesthetic or performance reasons?
The methods in NumericOp? They are called from multiple places which
does not have anything in common. So I put the methods in NumericOp to
[Simon]
In general, I have a different idea about the retain
condition. Retained spaces do not appear between areas returned by the
FO; all spaces appear before or after all areas returned by the
FO. This is different from retained padding and borders.
[Jeremias]
That's the part where I
[Peter B. West]
...
That code was alt-design properties code. It seems to me that many of
the ideas and implementation details of alt-design are now sitting in
the FOP code base. This is true whether Finn ever looked at the
alt-design properties code. It ain't over yet.[1]
I did, before
[Jeremias]
... the
transformation list is still necessary to recreate the same state after a break
out as needed when painting fixed block-containers. I haven't found a better
way to handle this case, yet.
Is there a reason for keeping areas from absolute and fixed
block-containers in the
[Andreas]
Hi all,
For starters: it's not really a pressing matter ATM, but it may become
of relevance if we want to strive for a production-release. The matter
is somewhat related to the distinction between developer- and
user-directed logging.
It concerns the numerous log.debug() and
[Andreas]
Have a look and let me know if it needs improvement.
Your renaming of whiteSpaceTreatment and whiteSpaceCollapse is a break
from the automatic naming of all the other property instance vrbl names.
I capitalized each '-' seperated word in the property name:
white-space-treatment
[Luca]
...
A little doubt concerning letter spaces: at the moment, a letter space
is assigned to the preceding character. Is this correct? I don't
remember any section in the specs stating about the ownership of
letter spaces ... I think that everything is simpler, from the point of
view of
Vincent Hennebert wrote:
Hi All,
Good news: before-floats are working. There probably are bugs and place
for improvement but I think it is time to submit a first patch, so that
you may see what I've done.
I'm currently cleaning up and documenting my code, and I think the
handling of the
29 matches
Mail list logo
