DO NOT REPLY [Bug 15119] New: - fo:external-graphic and border properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15119. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15119 fo:external-graphic and border properties Summary: fo:external-graphic and border properties Product: Fop Version: 0.20.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I want to render a graphic inside a box with the following properties : fo:external-graphic src=graph.png width=4in border-color=black border-width=thin border-style=solid/ the box is missing despite you mention that FOP is full compliant with these properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Border properties
Arved, thanks for the explanations. I still find it confusing that in the following (default western script) the left visible edges would not line up: fo:blockstuff/fo:block fo:block border-style=solid border-width=5mmMore stuff /fo:block In order to have it line up, the start-indent has to be set to 5mm. This, well, sucks. I'm pretty sure there are other who'll be confused too. Is this some CSS inheritance I have missed? I took a quick look at table.fo (the FO) and I think this will probably help out. I have to admit if there is one area of the spec that I am not particularly familiar with it is tables - in this case I don't think there is any weirdness involved stemming from table border properties. Well, table borders apparently are handled the same way as ordinary block borders, i experimented a bit. This appears to be consistent. The problem remains: Now, what is the problem bug 684 complains about? I still have no idea: is the problem fixed or not? For a start, I'm not quite sure what the problem reporter meant, because I've never seen tables.fo rendered by an older FOP version. I have to say it looks ok for me, but then I have missed important things before. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Border properties
I think I remember what was (!) wrong: There was a time where FOP displayed the table(s) on page 6 of table.fo in the following manner: +--- |bad +--- +-- |bad +-- +-- |bad +-- +-- |bad +-- The left indentation of each consecutive table (!) was incremented by exactly the left border width of the previous table. That bug was in FOP for quite a few months! I don't know anymore who fixed it in the end. So I'm going to mark the bug as closed for you. The problem remains: Now, what is the problem bug 684 complains about? I still have no idea: is the problem fixed or not? For a start, I'm not quite sure what the problem reporter meant, because I've never seen tables.fo rendered by an older FOP version. I have to say it looks ok for me, but then I have missed important things before. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Border properties
Hello, I tried to make something out of bug 684. Again, after reading the spec in depth, I'm nearly biting pieces off my keyboard. In the tables.fo examples, the left edge of the table content rectangle is the same as the edge of the reference area, and left border (should I use start edge border?) is tacked on so that it extends outside the reference area. The upper and lower border, however, do not overlap previous or following blocks, as expected. Well 4.4.1 says the start-edge of its allocation-rectangle ... offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below) minus its border-start, padding-start, and space-start values... given that the start-indent of the tables are zero (hopefully), the behaviour regarding the border extending left beyond the edge of the refernce area appears to be consistent with the spec, albeit IMO a bit counter-intuitive, because not consistent with what happens in BPD. Now, what is the problem bug 684 complains about? Does it mean the border in BPD should be handled similarly to what happens in IPD? Or does he mean something else? And, of course: is my understanding on how borders/padding should be handled resonable? I feel very confused. BTW what happens if both start-indent and margin-start were defined on the same block area? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Border properties
Comments intermingled.Default reference orientation and lr-tb writing mode assumed. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: May 5, 2002 1:34 PM To: fop dev Subject: Border properties Hello, I tried to make something out of bug 684. Again, after reading the spec in depth, I'm nearly biting pieces off my keyboard. In the tables.fo examples, the left edge of the table content rectangle is the same as the edge of the reference area, and left border (should I use start edge border?) is tacked on so that it extends outside the reference area. What it really boils down to is, the start-indent and end-indent are content-rectangle to content-rectangle distances. If the start-indent is zero then borders and padding and space are outside the content rectangle of the reference area. Similarly for end-indent. The upper and lower border, however, do not overlap previous or following blocks, as expected. I would not expect this - see below. At least not with initial values. Well 4.4.1 says the start-edge of its allocation-rectangle ... offset from it inward by a distance equal to the block-area's start-indent plus its start-intrusion-adjustment (as defined below) minus its border-start, padding-start, and space-start values... given that the start-indent of the tables are zero (hopefully), the behaviour regarding the border extending left beyond the edge of the refernce area appears to be consistent with the spec, albeit IMO a bit counter-intuitive, because not consistent with what happens in BPD. The treatment is different; there is no BPD counterpart to start-indent and end-indent. The separation between content-rectangles is determined by padding+border+space (before after). Borders and padding are length-conditional values so unless they are at the leading or trailing edge of a reference area they will definitely have the specified length. None of them are negative. The spaces _can_ be negative so this is the sole mechanism by which areas (including borders padding) can overlap (and space-specifier resolution is involved of course). Now, what is the problem bug 684 complains about? Does it mean the border in BPD should be handled similarly to what happens in IPD? Or does he mean something else? And, of course: is my understanding on how borders/padding should be handled resonable? I feel very confused. Join the club. :-) I constantly remind myself of what the definitions really mean in simple language. I also try to minimize use of allocation rectangles - I understand the concept but find it confusing. BTW what happens if both start-indent and margin-start were defined on the same block area? margin-* properties are absolute only (top, bottom, left, right). In any case, according to 5.3.2 and 5.3.1 the absolute properties take precedence. margin-left if explicitly specified has priority over start-indent. I took a quick look at table.fo (the FO) and I think this will probably help out. I have to admit if there is one area of the spec that I am not particularly familiar with it is tables - in this case I don't think there is any weirdness involved stemming from table border properties. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
