Re: Extension to write continued label in table headers
J.Pietschmann wrote: Karen Lease wrote: A while back, if I remember correctly, someone was looking for and perhaps going to write an extension to write continued labels in table headers. Ie, when the table continues, to add text like "(continued)" or whatever in the header (and/or footer). Apparently this never made it into the common pool, but I have recently cooked up something fairly simple (and limited) to handle this. Is there interest in putting it in for the next maintenance release ? It has very minor impact on the table layout code and probably would be useful to a number of people. Well, the functionality can be nearly emulated with standard XSLFO, even though it is somewhat messy, and perhaps some unwanted space appears. Therefore it can be discussed whether this should go into the FOP code pool. I needed this urgently for "real" work. The use of the static flow in this context would have been a real hack, whereas "continued" type functionality is a fairly standard part of real page layout systems. There were 2 or 3 positive responses to my message, so I put it in to the maintenance branch. As I wrote, it's quite limited, but at least now it's available for improvement, extension or integration in some larger context. A more generalized functionality would be FO which are conditionally rendered before/after page breaks in the FO which they are attached to: Continued on next page Continued from previouss page bla bla bla... Because there is now an EXSLFO initiative, I think we should supply a draft spec there and wait for some consensus before making comminments to the FOP code base (unless asked for proof-of-concept or something). I'll take care if writing the spec and submitting it, right after I've cleaned the backlog. Is this ok? Sounds fine to me, as long as you post your proposed spec here before posting it to EXSLFO. I think this functionality is most common in tables, but it can certainly be useful in a more general context. In any case, I already have a user request to do the opposite of "continued-label", ie: to compose some content only in the first area generated by an FO, and not in any remaining areas, so you might want to account for that as well. This brings up a point: is this type of functionality aimed at first/non-first/last area generated by a given FO, or by an area on a page (as in your example)? Note that if there are several columns on a page, these are not necessarily the same. Regards, Karen J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Another font-related issue: TTF ascender values
Hi everyone, Has anyone else noticed that the "ascender" values calculated for some TrueType fonts by the TTFReader seem to be very large? I have found this at least for the MS versions of Arial. It makes it look like there is a lot of leading (line-height) when there is not. In TTFFile.java, in the method readHorizontalHeader (used to read the "hhea" table, there is the following comment. ascender = in.readTTFShort();// Use sTypoAscender in "OS/2 table? In fact, the ascender values in the OS/2 table are smaller. In the OpenType specification, it says that the "hhea" values are Macintosh-specific. The commentary seems to indicate that the OS/2 values are closer to representing the actual font characteristics. At least for Arial, I certainly prefer the smaller values, but I haven't used other TTF fonts. Any opinions on this? If we make the change, it will change calculated font values and therefore have an effect on layout. Regards, Karen Lease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Thanks, I probably would have gotten around to it, but glad it's done. -Karen Jeremias Maerki wrote: I've committed your change to the trunk. I hope I haven't crossed your path. I've had a few other things I wanted to do in this region. On 20.11.2002 22:40:50 Karen Lease wrote: Hi Keiron, Feels good to do a little FOP :-) It's mostly work-related right now which explains why I'm hacking around in the maintenance branch. But it's better than nothing. I think this particular patch should work in trunk too, assuming no major differences in the embedding logic. I'll look into it. -Karen Keiron Liddle wrote: Hi Karen, Welcome back. Well if it works it looks good to me but I'm no font expert. Could that also be applied to trunk? Be careful the style police might get onto you. Keiron. On Tue, 2002-11-19 at 23:38, Karen Lease wrote: Hi all (and especially Jeremias or other font experts), This bug seems to be due to the way we generate the 'loca' table in the embedded font subsets (CID fonts). In fact, it has offsets to the correct glyph descriptions, but the offsets are not in ascending order. Since it seems that the length of the glyph description is found by subtracting the offset to the glyph from the offset for the next glyph in the loca table, this does not work. For Acrobat, as long as there actually _is_ a glyph description, it seems to work anyway. However for space characters, there is no glyph. Acrobat thinks there is because of the offset, so it draws the glyph that _is_ stored at the offset. This only shows up with SVG text because it has embedded spaces. The spaces in normal text are generally turned into explicit offsets and not drawn as such. The attached diff fixes the bug; though there are perhaps more elegant ways to do it. Does anyone see anything wrong with this idea? If not, I'll commit asap. In fact, using this fix, xpdf now also works with embedded fonts, whereas before it produced garbage. Regards, Karen Lease (Lately very overworked) Senior Software Developer SPX Valley Forge Paris/Munich Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Extension to write continued label in table headers
Hi Oleg, It looks like this: Heading (cont.) etc For now, the content of the continued-label element must be an fo:inline. It probably wouldn't be that hard to relax that, but it's better than nothing. The content of the fox:continued-label element is only written out on table-areas after the first one. I will commit it then ASAP. Note that this works in the maintenance branch only, but the element itself should be OK in the HEAD too, though the way it decides whether this is the first table area will need to be changed. -Karen Oleg Tkachenko wrote: Karen Lease wrote: A while back, if I remember correctly, someone was looking for and perhaps going to write an extension to write continued labels in table headers. Ie, when the table continues, to add text like "(continued)" or whatever in the header (and/or footer). Just yesterday there was one more such a question at fop-user. Apparently this never made it into the common pool, but I have recently cooked up something fairly simple (and limited) to handle this. Is there interest in putting it in for the next maintenance release ? It has very minor impact on the table layout code and probably would be useful to a number of people. +1, it would be great, how does semantics look like? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi Keiron, Feels good to do a little FOP :-) It's mostly work-related right now which explains why I'm hacking around in the maintenance branch. But it's better than nothing. I think this particular patch should work in trunk too, assuming no major differences in the embedding logic. I'll look into it. -Karen Keiron Liddle wrote: Hi Karen, Welcome back. Well if it works it looks good to me but I'm no font expert. Could that also be applied to trunk? Be careful the style police might get onto you. Keiron. On Tue, 2002-11-19 at 23:38, Karen Lease wrote: Hi all (and especially Jeremias or other font experts), This bug seems to be due to the way we generate the 'loca' table in the embedded font subsets (CID fonts). In fact, it has offsets to the correct glyph descriptions, but the offsets are not in ascending order. Since it seems that the length of the glyph description is found by subtracting the offset to the glyph from the offset for the next glyph in the loca table, this does not work. For Acrobat, as long as there actually _is_ a glyph description, it seems to work anyway. However for space characters, there is no glyph. Acrobat thinks there is because of the offset, so it draws the glyph that _is_ stored at the offset. This only shows up with SVG text because it has embedded spaces. The spaces in normal text are generally turned into explicit offsets and not drawn as such. The attached diff fixes the bug; though there are perhaps more elegant ways to do it. Does anyone see anything wrong with this idea? If not, I'll commit asap. In fact, using this fix, xpdf now also works with embedded fonts, whereas before it produced garbage. Regards, Karen Lease (Lately very overworked) Senior Software Developer SPX Valley Forge Paris/Munich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
Yes, definitely. +1 Karen Keiron Liddle wrote: Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Extension to write continued label in table headers
A while back, if I remember correctly, someone was looking for and perhaps going to write an extension to write continued labels in table headers. Ie, when the table continues, to add text like "(continued)" or whatever in the header (and/or footer). Apparently this never made it into the common pool, but I have recently cooked up something fairly simple (and limited) to handle this. Is there interest in putting it in for the next maintenance release ? It has very minor impact on the table layout code and probably would be useful to a number of people. Regards, Karen Lease Senior Software Developer SPX Valley Forge Paris/Munich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: basic-link brocken (maintenance branch)
Hi guys, If the problem is that the link rectangles are now merged by default, I am the one that changed it. There was a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9335 and I was doing a bunch of improvements to the positioning of the link rectangles. However, in this case, all I did was change the default merge behavior to yes. Is there something else broken? Regards, Karen Jeremias Maerki wrote: I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: Hi, I just discoverd that basic-link isn't working as expected in the maintenance branch (docs/example/fo/links.fo for example) It seems that mergelinks() is the problem so I'll change the default links.merge to no if there are no objections. (IIRC there has been some discussion about this but a quick search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi all (and especially Jeremias or other font experts),
This bug seems to be due to the way we generate the 'loca' table in the
embedded font subsets (CID fonts). In fact, it has offsets to the
correct glyph descriptions, but the offsets are not in ascending order.
Since it seems that the length of the glyph description is found by
subtracting the offset to the glyph from the offset for the next glyph
in the loca table, this does not work. For Acrobat, as long as there
actually _is_ a glyph description, it seems to work anyway. However for
space characters, there is no glyph. Acrobat thinks there is because of
the offset, so it draws the glyph that _is_ stored at the offset.
This only shows up with SVG text because it has embedded spaces. The
spaces in normal text are generally turned into explicit offsets and not
drawn as such.
The attached diff fixes the bug; though there are perhaps more elegant
ways to do it. Does anyone see anything wrong with this idea?
If not, I'll commit asap.
In fact, using this fix, xpdf now also works with embedded fonts,
whereas before it produced garbage.
Regards,
Karen Lease
(Lately very overworked) Senior Software Developer
SPX Valley Forge
Paris/Munich
Index: org/apache/fop/fonts/TTFSubSetFile.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/TTFSubSetFile.java,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 TTFSubSetFile.java
--- org/apache/fop/fonts/TTFSubSetFile.java 8 Nov 2002 10:25:26 - 1.5.2.2
+++ org/apache/fop/fonts/TTFSubSetFile.java 19 Nov 2002 22:29:00 -
@@ -311,29 +311,35 @@
pad4();
start = currentPos;
+int[] offsets = new int[glyphs.size()];
+
for (Iterator e = glyphs.keySet().iterator(); e.hasNext(); ) {
-int glyphLength = 0;
Integer origIndex = (Integer)e.next();
Integer subsetIndex = (Integer)glyphs.get(origIndex);
+offsets[subsetIndex.intValue()] = origIndex.intValue();
+}
+for (int i=0;i= (mtx_tab.length - 1))
+int origGlyphIndex = offsets[i];
+if (origGlyphIndex >= (mtx_tab.length - 1))
nextOffset = (int)lastLoca;
else
nextOffset =
-(int)mtx_tab[origIndex.intValue() + 1].offset;
+(int)mtx_tab[origGlyphIndex + 1].offset;
glyphLength = nextOffset
- - (int)mtx_tab[origIndex.intValue()].offset;
+ - (int)mtx_tab[origGlyphIndex].offset;
// Copy glyph
-System.arraycopy(in.getBytes((int)entry.offset +
(int)mtx_tab[origIndex.intValue()].offset, glyphLength),
+System.arraycopy(in.getBytes((int)entry.offset +
+ (int)mtx_tab[origGlyphIndex].offset,
+glyphLength),
0, output, currentPos, glyphLength);
// Update loca table
-writeULong(locaOffset + subsetIndex.intValue() * 4,
- currentPos - start);
+writeULong(locaOffset + i * 4, currentPos - start);
if ((currentPos - start + glyphLength) > endOffset)
endOffset = (currentPos - start + glyphLength);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Maintenance release: improvements to basic-link
Hi all, I haven't seen anything about the next maintenance release for about a week now, but I noticed that there had been some discussion about basic-link problems. In the meantime, I have improved the basic-link positioning and also made it work for external-graphic and foreign-inline-object, since I needed it for a project at work. It now works correctly when links are inside blocks and tables with before and/or after padding and borders; it also works inside list items in tables. The X positioning is corrected. Nothing else seems to be broken. :-) I've also changed the default behavior to make all the words into a single link rectangle; the current behavior can be forced by defining the system property "links.merge" to "no". If there are no objections, I will commit this to the maintenance branch. -Karen J.Pietschmann wrote: > Hi all, > we should think about getting 0.20.5 out of the door. > Yes, I know I'm behind with the doc, I really promise to > get it ready this weekend... > > As for the Bugs to be fixed, what should get in? > Choices: > 3. Harder stuff > - Links for non-text inlines(tried and failed: the > link was misplaced, I think I know why but may still > need some time) > - Links in static content (no idea) > J.Pietschmann > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style issues.
Your explanation couldn't be clearer. I now understand why the underscore doesn't bother me so much even though I'm not such a Heathen as not to use Emacs: 1) I type on a french keyboard and I don't have to shift to get the underscore character (only to get most every other useful character for programming); 2) I'm a fast typist and have never been much a fan of dynamic completion. And with that, perhaps we will let this topic slowly sink into the sunset and get on with useful programming once again :-) -KL J.Pietschmann wrote: [SNIP] > or perhaps being to lazy to properly configure my > default editor, and my keyboard layout causes some > more problems too: > - I hate prefixes which are shared by a lot of > identifiers > - I hate underscores in general > > For the Heathens and the Users Of Inferior Tools out there, > Emacs provides a dynamic completion function for identifiers. > Type in " s u b s " (or whatever key is used to invoke > the function), and the editor searches the file and will perhaps > present you "subSequenceSpecifier". Repeatedly pressing the > autocompletion key will present other possible completions. > > Obviously this is the reason why I have no fear of long > identifiers, and in fact I *like* them, because random abbrvs > can introduce subtle differences which can be overlooked during > autocompletion. > > Another effect is, if there are more than a few identifiers > in the file (or other files as they are searched too) which > share a common prefix, I have to type the prefix *and* a few > more characters to get the correct completion after the first > or at least after the second hit. That's why I'm not very fond > of prefixes, the longer the worse, and any rules which encode > whatever common information in prefixes. > > Using underscores in the prefix or to separate the prefix from > the real identifier makes it worse again. Obviously, I have to > key in the prefix and the underscore, which presents a few > interesting problems, in particular if the identifier is > camelCased. Keying in the underscore requires using the shift > key. If I miss this due to hasty typing, I get a dash, and the > completion won't complete. If I press the shift key too long, > the character after the underscore is capitalized, which > causes the completion algorithm to be case sensitive, and again > there is no match. Without the underscore, i never bother with > the shift key, because then the completion algorithm is case > insensitive and will even capitalize lower case characters > already typed in if necessary. > (note that this is not all that much a problem with the C > words_separated_by_underscores style, as I can often invoke > the completion successfully before an underscore has to be > typed). > > As I already noted, this can be fixed, and perhaps enhanced > to provide an even more intelligent completion algorithm, but > I'd rather think I'd take advantage of other people's dislikes > and get rules which will be ignored sooner or later anyway > canned before too much efford is wasted to introduce and > enforce them. > > Does this explain and help to understand my position? > > J.Pietschmann > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Keiron, Keiron Liddle wrote: > > The line height calculation and alignment is only very basic at the moment. > The idea is that the LineLM gets certain information to find the offset to > baseline and total line height and when the InlineLM add areas they use this > information to set the position of the inline areas. > > Yes, I noticed that you'd added this as well to the information returned in the BreakPoss. Now that it looks like things are heating up, we probably do need to do some cleanup before we get too much more code written. I agree with Joerg that we could simplify the inheritance now that we are only using the BP stuff. It wouldn't be so much work at this point to fold the BP versions back into the original interface and AbstractLM and to rename LineBP and TextBP. What do you think? The other thing I have been thinking about is how to structure the information we are returning in BreakPoss (besides the actual position part). In fact, it's really the same (more or less) information which we'll end up putting on the final Area we create, since a BreakPoss is really just a potential Area. I was wondering a while back whether we should just encapsulate an Area directly in the BreakPoss and use that to store the size information. On the other hand, some information won't be needed on the final areas (once they are positioned) such as the MinOptMax space around the area, the keep constraints etc, which are only used by the LayoutManagers while decided which BreakPoss to actually use to create the Area. Another general LM issue involves at which level to take into account the stacksize limit. For the inline stuff, I only used it at the LineLM level. I just had the lower level LM return each possible line-end and then let the LineLM decide whether it fit or not. When it got a BreakPoss which was too big, it could then decide to hyphenate, which means going into a kind of mode where it examines less optimal breaks. The equivalent of that logic on the block stacking level could be to have all block-level LM except the FlowLM return fairly large chunks (between block-level FOs for example) and then have the FlowLM ask them to break the block into smaller pieces when it gets a BreakPoss which overflows the current column size. I was originally thinking of having the block-level LM return on every Line, but that makes a lot of work and a lot of object creation, so it would probably be slow. For tables, I'd be tempted to always have the first layout pass return only breaks at row boundaries (or groups of rows linked by spanning cells) and only get into row-breaking logic if a) the row doesn't fit and there is no previous "good" break; b) the row and its cells don't have keep-together=always. Of course, if we get a row or a row group which is already starting a page and still won't fit, we have to break it anyway (or overflow it) in order to avoid the infinite loop problem. As you and Joerg were discussing the other day, exactly how to do the breaking in the row is very complex. If we try to optimize it we will get into some very deep decision trees with breaks in each cell. I tend to think that most tables should be set up to have keep-together=always. (Hint to the users!) On the other hand, there are cases where people are using tables to get some kind of special layout effect (unequal columns for example) and they want the cells to be able to be broken, so we can't get around this in the long run. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style issues.
Arved Sandstrom wrote: >>-Original Message- >>From: Peter B. West [mailto:[EMAIL PROTECTED]] >>Sent: August 20, 2002 9:51 PM >>To: [EMAIL PROTECTED] >>Subject: Re: Style issues. >> > [ SNIP ] > >> > The only encoding rule I'd realy like to have: >> > Don't mix underscores with camelCase. >> > Beside looking *really* ugly, it screws up Emacs' dynamic >> > identifier completion, and I'd rather like to do >> > something for FOP than fixing this. >> >>It comes down to "ugliness", doesn't it? "camelCase" is nice. I >>haven't heard it before, and I agree with your admonition. >> > This one is weird. :-) I have associated camelCase with Java, and expect to > see it. I dislike Microsoft naming conventions for VB and C# (I guess you > could call it capitalized camelCase, or Camelcase), without being able to > say why. And for C I cannot abide anything but underscore separators and all > lowercase. I think it is all a mater of habit. > > I may be a person who is ill-qualified to comment on variable names. I like > assembler and machine code, and I never had a problem with the variable > naming conventions for FORTRAN (I, J, K, L, M, N are INTEGER, etc). :-) Of > course, I started with punched cards so I was overjoyed to actually have > variables...sounds like a Monty Python skit (_you_ had _variables_?! I > walked 10 miles both ways to school, uphill, in deep snow, and I had to > hardcode the machine addresses on paper tape..._You_ had paper tape?! I > lived in a culvert, didn't go to school, and flipped switches on vacuum > tubes to set the program). > > Arved Hmm, perhaps that is my problem too; I still remember the PDP3 I had to boot with the front panel switches to make it read the paper tape and when I screwed up, I had to start the whole thing over! -Karen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Tony, Thanks for the advice. I have already started to look at the OpenType standard, in particular the parts describing the various baselines. Unfortunately I don't suppose I'll be attending the Unicode conference but perhaps someone here will be and could listen to Steve's talk and could report back to the group. However, it seems clear that FOP will definitely need to enhance the information it is managing about Fonts in order to provide the baseline information needed to implement these aspects of the spec. Regards, Karen Tony Graham wrote: > Karen Lease wrote at 20 Aug 2002 23:07:46 +0200: > > That would be good. I haven't looked at it for a month or so, but I had > > (as usual) some questions about various statements in the XSL-FO spec > > concerning the interpretation of the various properties. Perhaps we > > could go over those issues at some point. > > > Arved Sandstrom wrote: > > > > >>-Original Message- > > >>From: Karen Lease [mailto:[EMAIL PROTECTED]] > > > >>With regard to the line-height calculations, is anybody in the group > > >>interested in getting into the gory details of the baseline stuff for > > >>different scripts? I spent some time poring over the spec and trying to > > >>get a handle on this, but maybe it's too much detail for now. On the > > >>other hand, I'd really like to make sure that this version of FOP > > >>handles that stuff correctly as well as being able to do the various > > >>kinds of line-stacking strategies defined by the XSL-FO spec. > > >> > > > > > > I am definitely interested. I have put some thought into these things > > > already. Granted, when I implement it'll be a different codebase but I am > > > happy to work out the details on this list. > > You may be interested in Steve Zilles's statement in the abstract [1] > for his talk at next month's Unicode Conference where he says: > >The extended CSS/XSL model is based on the Open Type font >model. This model posits a set of alignment baselines for different >scripts, e.g., alphabetic, ideographic and hanging scripts. This >allows characters in a given script, but presented in different >font sizes, to be aligned on the baseline natural to that script. > > I just looked in the XSL Recommendation, and Section 7.8.1 notes: > >XSL uses an abstract model of a font. This model is described in >this section and is based on current font technology as exemplified >by the OpenType specification [OpenType]. > > Maybe you also need to look at the OpenType spec. > > Regards, > > > Tony Graham > > XML Technology Center - Dublinmailto:[EMAIL PROTECTED] > Sun Microsystems Ireland Ltd Phone: +353 1 8199708 > Hamilton House, East Point Business Park, Dublin 3x(70)19708 > > > [1] http://www.unicode.org/iuc/iuc22/a365.html > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Arved, That would be good. I haven't looked at it for a month or so, but I had (as usual) some questions about various statements in the XSL-FO spec concerning the interpretation of the various properties. Perhaps we could go over those issues at some point. Karen Arved Sandstrom wrote: >>-Original Message----- >>From: Karen Lease [mailto:[EMAIL PROTECTED]] >>Sent: August 19, 2002 6:58 PM >>To: [EMAIL PROTECTED] >>Subject: Re: Tasks - layout >> >> > [ SNIP ] > >>With regard to the line-height calculations, is anybody in the group >>interested in getting into the gory details of the baseline stuff for >>different scripts? I spent some time poring over the spec and trying to >>get a handle on this, but maybe it's too much detail for now. On the >>other hand, I'd really like to make sure that this version of FOP >>handles that stuff correctly as well as being able to do the various >>kinds of line-stacking strategies defined by the XSL-FO spec. >> > > I am definitely interested. I have put some thought into these things > already. Granted, when I implement it'll be a different codebase but I am > happy to work out the details on this list. > > Arved > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line breaks around dashes
Hi Jessica, That's a good question. As far as I've seen there's nothing official in the specification, so it's up to each implementation to handle this. I believe it falls in the category of things which could be defined by the "user agent" idea in FOP and then used by the line-breaking algorithm. In the redesign branch of FOP, the line-breaking code assumes it has a list of legal line-break characters; clearly this needs to depend on the script, which isn't yet the case. Regards, Karen Jessica Perry Hekman wrote: > Is there any way to ask FOP to allow line breaks before and after > particular characters -- in my case, mdashes? Apologies if this should > actually be specified in the FO; I've been trying to find a place in the > FO spec which says how to specify legal breaking characters, and I've > failed so far. It does seem to imply that a formatter should have access > to rules for legal breaking characters per script. > > j > > --- > "Users complain that they receive too much spam, while spammers protest > messages are legal." -InfoWorld > "You do not have to do everything disagreeable that you have a right to > do." -Judith Martin (Miss Manners) > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Keiron etc, I'm really happy to see all this movement going on and folks from the "maintenance" branch getting into the redesign to help you out. I'm hoping to be able to start contributing again too, perhaps not right away, but hopefully in September. There may even be some possibility of getting to work on FOP as part of my "real" work, though it might be hard to work on the new layout in that context. I'll keep the group posted. I'll start by looking at the latest and then maybe cogitating on list or table layout, depending on the timing and what others are interested in doing. It looks like status.xml is the sign-up sheet for the tasks; is that right? With regard to the line-height calculations, is anybody in the group interested in getting into the gory details of the baseline stuff for different scripts? I spent some time poring over the spec and trying to get a handle on this, but maybe it's too much detail for now. On the other hand, I'd really like to make sure that this version of FOP handles that stuff correctly as well as being able to do the various kinds of line-stacking strategies defined by the XSL-FO spec. Regards, Karen Keiron Liddle wrote: > Now that we have some pagination there are lots of areas that people can > work on. > If you want to implement any of these and have any questions then just > ask. > > Once we can get a few of these done then we could do a developers > release. > > > - Add static areas to page > The static areas will need to be handled in a similar way to the flow > except the bpd is unlimited and it will need to reset and repeat for > each page. > > > - Add id areas to page when area added > When the layout managers add an area to the page it can also add the id > information. > > > - Resolve id references on other pages, extensions > When an id is added to a page this will allow id references to be > resolved. > > > - Add markers to page when areas added > When an area is added that is created by an FO that contains markers > then the markers can also be added. There are four types of positions > for markers. > > > - Retrieve markers from page > When doing the static areas the markers wil need to be available for > retrieving. The marker can then be layed out as normal. > > > - calculate line height > The line height needs to be calculated while finding breaks. This needs > to include all the alignment and height details of the inline areas. > > > - Various inline objects > Page number, page number citation etc. need to be implemented. > > > - Implement page caching > If a page need to be stored for the store pages or waiting to resolve > forward references then we need a cache mechanism to save the page > somewhere. > > > - Implement table layout > The table layout will use the same technique as the block layout. It > will locate suitable breaks between rows or inside rows until table > finished or end of bpd reached. > > > - Implement list layout > The list layout like the table layout will be looking for suitable > breaks from the child objects. The it will add the appropriate areas to > the area tree. > > > - Get bookmark extension working > Make sure the extension id references are resolved. Once the data is > fully resolved then implement a way for the pdf renderer to add the > bookmarks. See branch for code how to add bookmarks. > > > These are just some of the things, I will add them to the todo list. > If there is a decent response then there are more that can be added. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style issues.
Hi all,
I see this started a few days ago, but I just came back from a couple of
weeks of vacation (and a couple of months of being totally buried in
work), so before I go back to the office, I'll at least let you know I'm
still around and even reading the list now and then :-)
I also recognize some of my code
J.Pietschmann wrote:
> Hello all,
> I just took a more extended look at CVS HEAD. There are
> some style issues which caught my eye.
> 1. I'd appreciate if indentation uses spaces instead of
>tabs. And because I can avoid using tabs, I expect
>everyone else avoiding tabs too.
> 2. I'd really, really appreciate if assignments were
>not made operands of other expressions, especially
>not operands of comparisions in if statements:
> if ((bp = getNextBreakPoss(childLC, null)) != null) {
>I'd make some exceptions for more commonly used idioms
>in while statements
> while ((curLM = getChildLM()) != null) {
>but IMO this still s*cks.
Probably comes from long years of writing C and C++ and avoiding extra
lines of code. Must be taste since I don't find it that bad, but if we
all vote it out in the style rules, I'll agree to banish it!
> 3. Exceptions should never, ever replace simpler flow
>controls:
> try {
> return super.nextChar();
> }
> catch (NoSuchElementException e) {
>if (bEndBoundary) {
> bEndBoundary=false;
> return CharUtilities.CODE_EOT;
> }
> else throw e;
> }
>Apart from the potential for confusion, throwing
>exceptions is an expensive operation and should really
>be reserved for rare and non-local exits. (In the
>particular case above, the discrepancy between hasNext()
>and getNext() seems to indicate a design bug that should
>be fixed rather than worked around).
Agreed, it would be better to recheck super.hasNext() rather than
letting it throw the exception. However, you'll note that the exception
is only propagated from this method in the case where it's hasNext()
returns false, which is the normal behavior for an Iterator.
> 4. Some identifiers make me a bit uneasy, like "BreakPoss".
>IMO random abbreviations should be avoided unless the
>identifiers become really long and unwieldy, at least
>in class names and preferably also in method names.
>Furthermore, I think abbreviations should be used
>consistently at least across class and method names:
> public void setStructHandler(StructureHandler sh) {
> public BreakPoss getBP() {
> protected Position getPos(Object nextObj) {
>Is it really worth to save a few characters this way?
>Also, capitalization should be consistent:
> class LMiter
> interface BPLayoutManager
Mea culpa. I quite agree with you that these names are not the best. All
I can say is that I was writing code in bits and pieces over a fairly
long period of time and wasn't paying enough attention to being
consistent with my BP (BreakPossibility) and BreakPosition (just
Position). I'm all for changing the names to something less confusing.
> 5. I don't think naming styles should be mixed without good
>(and preferably explained) reason:
> boolean m_bInited = false;
>Yuck!
> 6. There seems to be a drive to use hungarian notation.
>While I don't have a strong feelings for or against it,
>I'd like to note that in all projects I've watched such
>an efford was ultimately wasted. Usage universally
>degraded over time, and causal and inconsistent usage
>just makes the code look ugly.
Like most everyone else that's responded, I say, let's just pick a rule
that makes it clear what are member or static variables and which are
local and stick to it. Personally I tend to prefer m_xxx to this.xxx,
with or without hungarian.
...
> It would be nice to get some agreements nailed down and
> published.
>
> J.Pietschmann
>
>
All for that.
Regards,
Karen
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[REDESIGN - LAYOUTMGR] Status request/update
Keiron, I see you're currently occupied with lots of non-layout changes (structure renderer, IDs, etc). Are you also doing background work in the layoutmgr area or are you leaving the field open for me (and others of course)? I'm currently working on a block-level version of the inline-level "BP" layoutmgr logic I wrote. I hope to get simple block layout going by this weekend and hook it up with the inline BP managers. My plan is to have it handle break conditions, then keeps, followed by multi-column pages and spans. I've got some float handling logic jotted down but that is a bit further off! If you are other folks are preparing stuff in this area, let's try to coordinate. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Keiron Liddle Elected To ASF
Congratulations Keiron. You've certainly earned this with your steady contributions to FOP. Regards, Karen Arved Sandstrom wrote: > > Hi, all > > I am very pleased to announce that Keiron has been elected to membership in > the Apache Software Foundation, effective tomorrow (voting finished today). > I'd like to be the first to extend my hearty congratulations. :-) > > Regards, > Arved > __ > Arved Sandstrom > Sr Software Developer > Platform Products Group > Halifax R&D Office > Hummingbird Ltd > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[REDESIGN] Warning: hyphenation commit on the way
Hi all, Just a heads up. I've got some code to handle hyphenation in the new layout logic almost ready. Should be in tomorrow (Wed) or the next day. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[REDESIGN] New code for line breaking in nested inlines
Foppeuses, Foppeurs, I've added some new stuff to the development branch to show how the BreakPoss strategy would handle nested inlines. It doesn't do anything with blocks in inlines yet. For the moment, FOs are creating "BP" style layout managers for Inline, Text and Line. There's a new inline area class "InlineParent" which contains child inline areas. I've only modified the XML renderer for the moment to handle this. Also, the vertical alginment stuff is currently disabled, since I was only concentrating on handling breaks in nested areas and correctly propogating position information up to the Line LM. It should be able to get through the attached test case without crashing. Final warning: I sort of screwed up my commit. CVS looks ok, but some of the commit messages didn't get mailed. Please yell if you notice any problems. Sorry :-(( Regards, Karen http://www.w3.org/1999/XSL/Format";> Hello world. Here is a bunch of red text in an inline so that we can see if this will cause several lines to be made. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi Keiron, I think this is a good start. I especially like the illustration which covers all aspects of the problem. I have some suggestions for the proposed text (see below). -Karen Keiron Liddle wrote: > > Hi devs, > > I have attached a picture of how I think this process should work (in > principle not necessarily with actual areas or code). > > The spec should say something like: > > 4.7.2 > A block level formatting object which contains inline level formatting > objects that will create inline areas will create lines. "A block level formatting object may contain both other block-level and inline level formatting objects. The block level FO creates and returns a block area or several block areas if it is split across more than one column or page." > Any block level areas that are return[ed] by child formatting objects will > be placed as direct children of this block area. > Any inline level areas which are[a] return[ed] by child formatting objects > will be placed into line areas. > Consecutive inline areas will be placed into line areas. Minor corrections in "[]" above. > The sequence of child areas returned to this block area will be handled > so that a sequence of inline areas will be placed into a sequence of > line areas and block areas will be placed in the correct order. Not sure this is quite clear enough; it also needs to express the idea that the ordering between the intermingled blocks and inlines is correct. > (part 5. point 1 then says that any child fo that returns a block area > means that the block area is a direct child of the current block area) > > 4.7.3 > An inline level formatting object creates and returns inline areas and > returns any block areas. Each line area can contain only one inline area > created by the inline level formatting object. This inline area is > created by adding child inline areas that are allowed in the parent line > area (it is not required to fit, eg. no wrap). I'm not sure this is the right place to mention linebreak and overflow issues. The main idea is that an inline-level FO creates at least one inline area which holds inline areas generated and returned by any inline level child FOs. It might generate several inline areas, each one being placed in a new line area, if all its content doesn't fit in a single line. If the inline has any block-level FO descendants the block areas which they generate are directly returned by the inline FO. > 6.6.7 (and other inline fo's) > Areas: > The fo:inline returns these areas, any block areas, any > page-level-out-of-line ... > > > > So does that make more sense? > I think some of the confusion is that a block area can create multiple > block areas but this only occurs at page/column breaks. I assume you mean a "block level FO can create multiple block areas". And similarly, an inline level FO can create multiple inline areas if it is broken into several lines. > Regards, > Keiron. > > >Name: line.svg >line.svgType: image/svg >Encoding: base64 > >Name: line.gif >line.gifType: GIF Image (image/gif) >Encoding: base64 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, I'm definitely in favor of deciding how we think things are supposed to be laid out. Of course it would be nice if we were on the same wavelength with the majority of FO users and implementors... but I'm not too worried about that. Besides the stuff we're talking about currently, we need to agree on line-stacking issues (Keiron's already worked on vertical alignment, so he's probably up on that) and space specifier handling (but there I think the spec is fairly clear once one has read it 50 times or so :-). Arved Sandstrom wrote: > Good...if we all agree with that then I think it is the main point gotten > out of the way, because every other situation has to do with child FOs all > being inline or block-level, for which the results are less dubious. . > The main thing is, let's make sure that we have agreement (codified through > use of these diagrammed examples) on all matters that affect placement. I > understand that we want to have a warm fuzzy about our understanding of the > spec, but that's not going to happen with everything. > > To be precise, if I can get a number of these examples created, what we can > do is identify situations where we can say, this one is 100% solid (we know > this is right, there is no uncertainty in the spec), this one is iffy (there > may be small inconsistencies between our placement and what the spec authors > intended), or this one is problematic (contradictions, for example). > > Once we have classified the examples, we can do damage control on the > uncertain ones. Namely, let's do it this way, but let's be aware that things > could be interpreted another way, and if so, how heavily committed are we in > our code? > > On a related matter when it comes right down to brass tacks I am really only > concerned about placement (accuracy of rendering). Both with Fop and with my > other project I find it easier to use the conceptual areas, and I get the > sense that others also feel this way, but let's face it, as long as our > final result is consistent it doesn't really matter if our internal > structures deviate. > In general yes. So long as the extra levels of area "wrappers" we might or might not add in any given situation don't bring along border, padding, space-* etc. -Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Not really. As a fairly interested party, I must admit that mentions of throwing it out and starting over don't leave me totally indifferent, but I've got little enough time as it is for FOP these days, and I'm trying not to let myself be distracted. In any case, we all know that it's never right the first time around. Regards, Karen "Peter B. West" wrote: > > Hello devs. > > Does the near-silence on this one signify consent? > > Peter > > Keiron Liddle wrote: > > > Hi Peter and others, > > > > What is the status of property handling? > > > > Are we going to go with Peter's suggestion and commit the java source > > to cvs and work on handling properties fully from there? > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Peter, Here's my point of view on where line-breaking (perhaps including hyphenation) happens. The end result of layout is a sequence of nested areas. However while layout is happening, line-breaking logic has to "pretend" that it's only working on a flat row of characters and other inline leaf nodes like external graphics. Keiron and I took different approaches to this, but the idea is about the same: lower level layout managers return information to the Line Layout Manager which allows it to make a decision about where to break the line. Once that decision is made, the appropriate areas can be created, depending on where the break occurs. Although it's possible to send information about IPDim down to lower level inline layout managers, I think it's simpler and clearer to concentrate knowlege (and strategy) about line-breaking in a single layout manager: the one actually creating Line Areas. There's a strong analogy with block-direction layout, where the Flow level (or perhaps the Page level?) LM is responsible for determining column/page breaks based on information provided by the lower level layout managers. The Flow and Line level LM are also responsible for "justifying" in either the inline or block progression dimensions and deciding how much stretch or shrink should be done. They either pass this information down to lower level layout managers (that was my plan) or do it directly on the flattened areas (Keiron's approach, at least at the line level). -Karen "Peter B. West" wrote: > ... > This leaves a question about where hyphenation is decided. In 4.7.2 > point 5, there is a discussion about glyph substitution, insertion and > deletion which seems to assume that the sequences of inline-areas being > built into line-areas are in fact fo:characters. The corresponding > sequences bubbling up from fo:inline and fo:basic-link are already > wrapped as integral inline-areas and presented as a fait accompli to the > parent line-builder. > > The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim > information in order to present sane integral inline-areas to its > parent, and to allow for the layout of nested fo:blocks. (This is pure > hierarchical galley stuff.) In any case, there should be a correspondent > in 4.7.3 to the discussion of substitution, insertion and deletion in > 4.7.2, just to make it clear what the responsibilities of the > inline-builder are. That's if I have this right, this time. What do you > think? > Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, Keiron et. al. I guess logically it's true that the blocks nested in inlines should be wrapped in inline areas, but it makes me nervous :-) At least they cause line breaks, that much seems sure. I still think that we should put pressure on the spec editors to either get rid of structure or clarify it in the next version (ha, ha). If people need blocks in inlines, they have inline-container. In fact, I'd like to think that the possibility of including block-level FOs in inline-level FOs is purely for convenience or "semantic nesting" and should not really affect the area tree, except to cause line breaks before and after the block areas. The most legitimate use I can see for this kind of semantic nesting is basic-link, because it could spread the link semantics over several areas; kind of a link-wrapper. - For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. Also, if we look at 4.7.3 (inline-building), I find it curious that it starts by saying TWICE that an inline FO places inline areas and anchor inline areas returned by its child FOs in inline areas which it generates, and then suddenly throws a block-area into the condition described in point 1. Looks more like a hasty copy/paste from the list for Line-building! As Keiron says, if the spec writers had been clearer, we wouldn't have to spend hours chasing our tails like this! Regards, Karen Arved Sandstrom wrote: > [SNIP] > > _If_ there were blocks nested inside the top-level block these would produce > normal block areas that are single children of normal block areas produced > by the top-level block. My reading of Line-Building is that normal block > areas generated by a fo:block have either _single_ block areas _or_ one or > more line areas as children, not a mixture. > > Final comment: it is the close intermingling of inlines and blocks in this > example that causes so much line breaking. Clearly each of the 2 nested > blocks could be wrapped in inlines (fo:inline or whatever), and as a result > everything in the example, in theory, could be in _one_ line area. > > Anyhow, please critique away. :-) > > Regards, > Arved > > > Name: complex_block.png >complex_block.pngType: PNG Image (image/png) > Encoding: base64 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[REDESIGN] Line layout manager discussion
yout process should start as soon as the first block is > ended (no matter how deep it is). So something like, when starting a block > level element the layout manager is added to the parent, when a block > level element is ended then the layout process starts and adds the areas > from that block etc. > How this will happen in practice I haven't really thought about. If the > iterator can do that then we should use it. That's my theory too. I think an iterator over the child LayoutManagers (which is more or less an interator over the child FOs), can be written to get the next child if available and if not to "wait" (the consumer thread). It would then be awakened by the thread building the FO tree (the producer) when it had completed a block-level FOnode. There needs to be something indicating when an FO is complete so the consumer will not be eternally waiting on more children to arrive! > On 2002.04.29 00:16 Karen Lease wrote: > > Hi Keiron, > > > > Here are a few comments on your new layoutmgr stuff (which is definitely > > more advanced than mine in most ways) : > > > > 1. I can't figure out how/where you manage space-start, space-end, > > border, padding, background etc (ie, any non-inherited properties) for > > non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said, > > you're "flattening" the inline LM, so in fact, you're just adding the FO > > children of the inline. I think that if these FO _must_ create real > > inline areas if they have any non-inherited properties. If they don't > > they are acting kind of like fo:wrapper, and in that case, I agree we > > don't need a separate layout manager, because no area needs to be > > created. > > > > For basic-link, I think it would also be easier if it created an inline > > area containing its child areas even if it doesn't have any > > non-ineritable layout type properites. We could hang the linking > > information on that area (or areas, if it split across lines). > > > > But if we make nested inline areas, then the space adjustment as written > > in the LineLayoutManager won't work correctly, because it won't see the > > nested spaces. > > > > 2. Lack of context information: I ended up adding a LayoutContext oject > > to pass information down to the LM(s) generating the areas. This is to > > handle things like space-specifiers which can accumulate from various > > tree levels, and also to indicate when a LM is generating a break (or an > > Area) which is first in its parent area. That can influence things like > > conditional space and borders and padding. What's a pain with that stuff > > is that it changes the IPD, so until we know where the area is going to > > be placed, we don't know exactly how big it will be. > > > > 3. I'd like to avoid having to generate all the child LM before starting > > to layout any given level. This would limit us to waiting for a whole > > fo:flow to be done (unless we special case at that level). I think we > > can find a way to "pull" on the layout managers and still keep the > > flexibility you gain with the addLayoutManager(List) approach. I think > > it could be done with some kind of Iterator. (OK, I'm on kind of an > > Iterator fling recently, but they _are_ really handy. :-) > > > > Regards, > > Karen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (coments on Keiron's commit)
Hi Keiron, Here are a few comments on your new layoutmgr stuff (which is definitely more advanced than mine in most ways) : 1. I can't figure out how/where you manage space-start, space-end, border, padding, background etc (ie, any non-inherited properties) for non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said, you're "flattening" the inline LM, so in fact, you're just adding the FO children of the inline. I think that if these FO _must_ create real inline areas if they have any non-inherited properties. If they don't they are acting kind of like fo:wrapper, and in that case, I agree we don't need a separate layout manager, because no area needs to be created. For basic-link, I think it would also be easier if it created an inline area containing its child areas even if it doesn't have any non-ineritable layout type properites. We could hang the linking information on that area (or areas, if it split across lines). But if we make nested inline areas, then the space adjustment as written in the LineLayoutManager won't work correctly, because it won't see the nested spaces. 2. Lack of context information: I ended up adding a LayoutContext oject to pass information down to the LM(s) generating the areas. This is to handle things like space-specifiers which can accumulate from various tree levels, and also to indicate when a LM is generating a break (or an Area) which is first in its parent area. That can influence things like conditional space and borders and padding. What's a pain with that stuff is that it changes the IPD, so until we know where the area is going to be placed, we don't know exactly how big it will be. 3. I'd like to avoid having to generate all the child LM before starting to layout any given level. This would limit us to waiting for a whole fo:flow to be done (unless we special case at that level). I think we can find a way to "pull" on the layout managers and still keep the flexibility you gain with the addLayoutManager(List) approach. I think it could be done with some kind of Iterator. (OK, I'm on kind of an Iterator fling recently, but they _are_ really handy. :-) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (part 2)
Hi Foppers, I've gone ahead and committed the major part of the Break Possibility approach to layout managers which I have developped. It leaves Keiron's new code intact (except for a couple of changes I needed to make to be able to subclass his LineLayoutManager). It's also not activated; to do so there are two changes to make: org.apache.fop.fo.FOText: create a TextBPLayoutManager instead of a TextLayoutManager org.apache.fop.layoutmgr.BlockLayoutManager: create a LineBPLayoutManager instead of a LineLayoutManager Both changes are in comments. This code will run for blocks containing text but not much else. It's mostly just to illustrate the idea. I didn't try to work in the block-level versions of the BP layout managers, at least not for now. In most ways, it's a good deal less functional than Keiron's code; however it does have some code to handle resolution of sequences of space specifiers, and the text layout code has the start of some word-space handling. It might be helpful to have another look at the design document describing the general idea when looking at the code. Regards, Karen Keiron Liddle wrote: > > Hi Developers, > > I just committed a bunch of changes to the line layout. > I think it now has a reasonable basis to further develop the inline level > areas and build line areas. > If you run it over alignment.fo or instream.fo you will see that it mostly > works for these examples. > It does the spacing and vertical alignment. [SNIP] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved, I think the "ownership" idea is a good one. Especially since we now have some new committers who are full of energy and we have a batch of new code in the "redesign" branch which people can (and should!) look at and respond to. I think we can start like this: a) review the code which Kerion and I have committed in the last couple of days. b) discuss it here on the list; if it would then seem useful to have a more instantaneous forum to work out issues, we can work on setting that up. c) parcel out work on the code to various owners. There's lot's to do, so no one should feel left out. d) Communicate on the list (I think it's better than using the Status file, more spontaneous) about what we intend to do in the next "iteration" (next couple of weeks say). We could use a specific tag line like [PLANNING UPDATE] or some such so these messages wouldn't get lost in the forest. Regards, Karen Arved Sandstrom wrote: > > I have some thoughts and suggestions, some of which we might adopt with > varying degrees of success. > > 1. I can see a place for structured (that is, planned) communication: > conference calls, scheduled meetings on a system like Peter describes, use > of something like MSN Messenger, setting up an IRC channel and everyone > getting together there. But I don't think that's the problem at the moment. > > 2. Can we do better with CVS? Maybe...reserved checkouts is overkill but > perhaps watch features are indicated. We currently get commit notifications > (I suspect through loginfo, probably, rather than a watch feature), but we > don't know when someone started work on a file. If we used watches, we could > set things up so Karen might get notifications on 'cvs edit' for > such-and-such a package, Peter might get 'cvs edit' notifications on another > package that he selects, and so forth, whatever is of interest. > > This would at least give us notifications at the other end of the process, > which is when a developer (say, Keiron) _starts_ to work on a file. > > This is a bandaid, though. I am just as bad as Karen when it comes to > wanting to have everything just-so before I check something in. This is OK > with reserved checkout systems like SourceSafe default, but it's lousy for > the unreserved checkout CVS case. > > I would nevertheless suggest maybe trying the watch features. I would > otherwise really stress the use of a single-point-of-reference file, like > STATUS, but I have my doubts about that. It has not proved out so far. What > would be really sweet is if we had a visual aid that supplemented cvs watch > features, maybe a page on the website that you could access that would > indicate that a certain developer has run 'cvs edit' on file A, for example. > Maybe ViewCVS does this already, I don't know. > > What we lack is ownership. We've got a whack of committers and a fair-few > active ones, and maybe it's now time to allocate ownership of stuff on both > branches. Ownership does _not_ mean you are the only person working in that > package or packages - what it means is you are the POC for work being done > in that package. You are the arbiter of disputes. We could even combine this > with BugZilla ownership, possibly. > > Comments? If folks are agreed or at least not against it I can set up what > needs to be setup. > > Arved > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Karen Lease > > Sent: April 27, 2002 12:20 PM > > To: [EMAIL PROTECTED] > > Subject: Re: line layout commit > > > [ SNIP ] > > > > At any rate, I'm certainly not averse to having some more structured > > kind of communication about where to go from here be that a chat or just > > some discussion on the list of where we are and where we should go. As I > > mentioned, I'm going to dive in to his new stuff and study it carefully > > today and tomorrow; I'll probably have some questions and remarks at > > that point. > > [ SNIP ] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Hi Peter, Well, it certainly is due to some kind of communication problem, and I think it's largely my "fault" if fault there is. I have a really hard time committing havf-finished bits of code, so no one's heard a peep from me in a while. And I think the long BreakPoss design doc I submitted in mid-March wasn't enough to indicate that I was working on this idea, or perhaps that I was working on the inline aspect first. At any rate, I'm certainly not averse to having some more structured kind of communication about where to go from here be that a chat or just some discussion on the list of where we are and where we should go. As I mentioned, I'm going to dive in to his new stuff and study it carefully today and tomorrow; I'll probably have some questions and remarks at that point. But I think Kerion's definitely the lead here; he's been a lot more regular than I for some months now, and that probably will be true for a couple months more at least (unfortunately for me, since I am frustrated to be able to devote so little "quality" time to FOP, but c'est la vie...). Regards, Karen "Peter B. West" wrote: > > K, K, A and other developers, > > Regular chat sessions would probably have been useful here, and I think > that they might still be useful. Probably every interested party but me > is in the time zone spanned by Keiron and Arved. Anyone in the US? It > should be possible for you to arrange some times. I would love to > eavesdrop, and I would try to attend. What times would suit the three of > you? Do you think it would be useful? > > Peter > > Karen Lease wrote: > > >Hi Keiron, > > > >On the one hand, I'm happy to see new work in the LayoutManagers. > > > >On the other hand, it turns out, I have been plugging (unfortunately > >really slowly) away at the Break Possibility ideas I mentioned a while > >back and just this very evening I had gotten the Line and Text > >LayoutManagers to where they were actually generating areas based on the > >BreakPoss ... and maybe it was ready for CVS. > > > >... really I'm not kidding. > > > >That was when I discovered that you had beat me to it by a few hours. I > >only saw your "thinking aloud" mail last night and my feeling was that > >apart from the "flattening of inline LM" idea, there might not be such a > >big difference in our approaches. But of course, the code itself is > >quite different. > > > > > >Arved Sandstrom wrote: > > > > > >>Very cool. I will try to pry away from my other project and also doing my > >>income taxes and put in some quality time checking this out this weekend. > >>Sounds like we are basically at the point where a bunch of us can usefully > >>pitch in. :-) > >> > >> > >> > >>>-Original Message- > >>>From: Keiron Liddle [mailto:[EMAIL PROTECTED]] > >>> > >>>Hi Developers, > >>> > >>>I just committed a bunch of changes to the line layout. > >>>I think it now has a reasonable basis to further develop the inline level > >>>areas and build line areas. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your "thinking aloud" mail last night and my feeling was that apart from the "flattening of inline LM" idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. I had done a bunch of work in Text and Line LM, but mostly it was totally new code, so after the CVS update your new stuff and mine are more or less coexisting. But I'll have another look at this tomorrow when I'm less tired to understand the details of your new stuff and to see if there's any useful way to integrate mine into it. It looks like you didn't change TextLayoutManager that much, so maybe some of my changes there could be worked in. The big difference is that I'm first generating a bunch of "BreakPoss" on the inline level which the LineLayoutManager is using to choose a break. In theory, it could do this for several lines at a time, but right now, it's just trying to do one. The the LineLM is also generating BreakPoss which represent the LineAreas it would create. Those eventually get bubbled up to the FlowLayoutManager which does basically the same thing as the LineLM. When it's happy, it uses the BreakPoss objects to have all the lower level LM generate the actual areas. I'll also have to adapt to the switch between getLayoutManager and addLayoutMangers though. I remember you mentioning this a while back, but I had continued to work along the original path. Don't think that will be too hard to do though. What I liked about the original approach is the idea that we could be laying out the tree in one thread and building it in another. But maybe that's still possible, just on a different level of chunking. At any rate, I'll try to see if I can add anything useful to your work. Do you think it's worthwhile trying to integrate the BreakPoss stuff or to commit it in some form so it would be public? -Karen Arved Sandstrom wrote: > > Very cool. I will try to pry away from my other project and also doing my > income taxes and put in some quality time checking this out this weekend. > Sounds like we are basically at the point where a bunch of us can usefully > pitch in. :-) > > As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have > you looked at the Java reference implementation for it? :-) Not a trivial > thing. > > Arved > > > -Original Message- > > From: Keiron Liddle [mailto:[EMAIL PROTECTED]] > > Sent: April 26, 2002 10:16 AM > > To: [EMAIL PROTECTED] > > Subject: line layout commit > > > > > > Hi Developers, > > > > I just committed a bunch of changes to the line layout. > > I think it now has a reasonable basis to further develop the inline level > > areas and build line areas. > > If you run it over alignment.fo or instream.fo you will see that > > it mostly > > works for these examples. > > It does the spacing and vertical alignment. > > > > The main things that need thinking about are: > > - range properties > > - wrapping (ie. no wrap) > > - whitespace and linefeed handling > > - Unicode BIDI (this looks hard) > > > > It is very rough at the moment, the idea is to get a basis so that inline > > areas can be created and put into line areas and this will fit into the > > overall design. > > > > This leaves us with a simpler way of handing inline areas. > > > > So whats next? > > > > It is possible to start looking at fully implementing inline areas, eg. > > image, instream-foreign-object, leader, character. > > Getting pagination working will be a big step forward. > > Then we need to block area layout managers, like tables and lists. > > > > So what do people think? > > > > > > Regards, > > Keiron. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Vote] New committers: Peter West, Joerg Pietschmann (and Jeremias Maerki)
Excellent idea: +1 for Peter, Joerg and also Jeremias -Karen Keiron Liddle wrote: > > I propose that we offer Peter West and Joerg Pietschmann to become > committers. > > Peter has of course shown lots of commitment of the last year+. > Joerg is helping a lot with user questions FAQ etc. > > If they accept then I am sure it will help with the valuable work they are > contributing to FOP. > > Needless to say I am +1 for both. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Website update
Thank you Jeremias. I've committed it. Regards, Karen Jeremias Maerki wrote: > > Hi there > > Since Michael did the first cut at the logging stuff and Jörg has > already submitted something on JAXP, I made the best out of my day off > and happily hacked around in the xml-docs directory. I hope you will > like it. > > What I've done: > - Added a page "How to get Help". > - Added documentation for Michael's logging changes. > - Corrected some minor typos. > - Restructured the Resources page a bit. > - Added some more information on the PostScript Renderer. > - Added a comment on the FormattingResults class in "Embedding". > - Added a comment on CVS branches. > - A few other little additions. > > gethelp.xml is new and goes into docs/xml-docs/fop. > > Cheers, > Jeremias Märki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Break Possibility scheme in new layout
Hi Arved, I actually have bits of code using BreakPoss lying around that I am going to try to commit rather quickly. It doesn't work yet, but it will give people some ideas. Not sure it will be this week though, since I'm away on business the whole week. Depends on if the hotel room has a modem port :-) I've seen that you are making strides on xslfo-proc, but haven't taken the time to look at it at all. Not that I wouldn't like to, but my resources are limited right now. I'm not convinced that the tree building approach is that much different than the SAX one either. In fact, the layout managers are really only looking at one child at a time, so that they could be running in parallel with the FO tree building. Since tree building is done by SAX, they could also be pipelined with that. The FO reader/builder is pushing and the LM are pulling. Does that make sense, or am I just blathering on? Regards, Karen Arved Sandstrom wrote: > > Hi, Karen > > Well, _I_ am interested. :-) Already scanned it once, but I'll definitely > give it a thorough read quite soon. > > I think I might be able to resume contributing to FOP layout stuff sooner > than I thought. I don't mean the image stuff which is still on my plate but > more the guts that you and Keiron have already been tackling. The design > ethos that I see expressed in the new FOP so far conforms to how I would do > things anyway - we had lots of discussion about it last year and I don't > recall that anyone expressed dissatisfaction with the idea of managers. I > certainly didn't. :-) > > In fact I am using managers in my xslfo-proc prototype. They are really > rough around the edges at the moment but I expect to have fairly clean code > and good design docs for a first prototype release in about 2 weeks. I > already had "First PDF" yesterday, albeit on a very simple example, and not > without errors. I am hoping that much of the layout design in xslfo-proc can > conform rather closely to New FOP, so that if in future the production C/C++ > codebase gets folded back into Apache XML FOP, that there will _not_ be > distinctly different designs. > > The main difference I believe is that the tree-based FOP approach lends > itself to more layout sophistication at less cost (in understanding and > complexity) than does a SAX-based approach like xslfo-proc. But because a > SAX-based XSL formatter must also maintain a working subset of FOs, raw > layout, managers, and areas, at some point the approaches blur into each > other. The main difference is other requirements - in the case of xslfo-proc > one of those is memory, so some sophistication will be sacrificed in order > to minimize storage. Ironically, the existing FOP, for all the advantage > that it takes of having the entire tree available to it, may as well have > been written using SAX directly. But I think another advantage of having > xslfo-proc in the wings is that it may provide pointers as to how the new > FOP can be moved to SAX, with little actual impact, hence addressing memory > concerns. We'll see. > > In fact I am switching to FOP for the rest of the day, to start looking at > the image layout, so I'll be mixing stuff up a fair bit from now on. > > Regards, > Arved > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Karen Lease > Sent: March 17, 2002 12:19 PM > To: [EMAIL PROTECTED] > Subject: Break Possibility scheme in new layout > > Hi, > I wrote a fairly detailed description of the Break Possibility idea and > put it in the design docs section, for anyone who's interested. > > Could someone please tell me the procedure for getting the html version > of the design docs regenerated on the web site? Or does this just > magically happen? > > Thanks, > Karen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Break Possibility scheme in new layout
Hi, I wrote a fairly detailed description of the Break Possibility idea and put it in the design docs section, for anyone who's interested. Could someone please tell me the procedure for getting the html version of the design docs regenerated on the web site? Or does this just magically happen? Thanks, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: BUG? Row data breaks over a page within a column]
Hi Matthew, You're right, it really shoulldn't do this. However you can keep it from doing it by putting the keep-together="always" attribute on the table-row containing the cell which is breaking. Keep-together doesn't work yet for block, but at least in this case, it does for table-row. Like this: Total More Budget Data HTH, Karen Matthew Mastracci wrote: > > I posted this to the fop-user list, but I think it might be better to > post it here. > > > > Subject: BUG? Row data breaks over a page within a column > Date: Thu, 07 Mar 2002 13:08:30 -0700 > From: Matthew Mastracci <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > I think I mave have encountered a bug. The attached XSL:FO file renders > in what I think is an incorrect manner with FOP 0.20.3. > > The column itself ends up being split across two pages. The row, > however, contains a column with "number-rows-spanned". I thought that a > column with "number-rows-spanned" would be kept together across a page > break- breaking in the middle of the row seems to be an error. I've > tried adding the keep-together="always" attribute and it still seems not > to work. > > The column cells with borders are where I think the problem is. > > Thanks! > Matt > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FopServlet
Deb, Which version of tomcat are you using? Especially with Tomcat 3.x I've seen lots of classloader problems. Can you find out which jars are being used by tomcat (in its lib or maybe lib/ext directory)? Look out for jaxp.jar or perhaps a version of xerces at that level which would be pulling in xalan. What can happen is that the javax.xml.transform is found in tomcat's jaxp.jar and if it's set up to use Xalan, it will only look for it in tomcat's classpath, not in your own webapp classpath, which seems to have the right stuff in it. Also do have any XML type jars in your java or jre lib/ext directory? HTH, Karen Deb Schmutz wrote: > > I believe I have all the jar files that I need. Here > is what my war file looks like: > > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/lib/ > WEB-INF/lib/ant.jar > WEB-INF/lib/avalon-framework-4.0.jar > WEB-INF/lib/batik.jar > WEB-INF/lib/bsf.jar > WEB-INF/lib/buildtools.jar > WEB-INF/lib/jimi-1.0.jar > WEB-INF/lib/logkit-1.0b4.jar > WEB-INF/lib/stylebook.jar > WEB-INF/lib/xalan-1.2.2.jar > WEB-INF/lib/xalan-2.0.0.jar > WEB-INF/lib/xalanj1compat.jar > WEB-INF/lib/xerces-1.2.3.jar > WEB-INF/lib/fop.jar > WEB-INF/lib/servlet.jar > WEB-INF/classes/ > WEB-INF/classes/FopServlet.class > images/ > images/CompHealth-Logo.gif > WEB-INF/web.xml > > --- "Volker [EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > It looks as if your tomcat installation does not > > pick up Xalan.jar. > > You have to put all FOP jars (fop.jar, batik.jar > > etc.) into > > /WEB-INF/lib/ > > directory. > > > > Hope this helps > > > > Volker > > > > -Original Message- > > From: Deb Schmutz [mailto:[EMAIL PROTECTED]] > > Sent: Monday, March 04, 2002 2:17 AM > > To: [EMAIL PROTECTED] > > Subject: FopServlet > > > > > > I am new to Fop and having problems with the > > FopServlet that came with Fop-0.20.2. Please can > > anyone give me any pointers. TIA. > > > > Error: 500 > > Location: /fop/fop > > Internal Servlet Error: > > > > javax.servlet.ServletException > > at FopServlet.renderXML(FopServlet.java:135) > > at FopServlet.doGet(FopServlet.java:77) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:740) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) > > at > > > org.apache.tomcat.core.Handler.service(Handler.java:287) > > at > > > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > > at > > > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 > > 2) > > at > > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) > > at > > > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC > > onnectionHandler.java:213) > > at > > > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > > at > > > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) > > at java.lang.Thread.run(Thread.java:484) > > > > Root cause: > > org.apache.fop.apps.FOPException > > at > > > org.apache.fop.apps.XSLTInputHandler.getParser(XSLTInputHandler.java:109) > > at FopServlet.renderXML(FopServlet.java:128) > > at FopServlet.doGet(FopServlet.java:77) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:740) > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) > > at > > > org.apache.tomcat.core.Handler.service(Handler.java:287) > > at > > > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > > at > > > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 > > 2) > > at > > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) > > at > > > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC > > onnectionHandler.java:213) > > at > > > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > > at > > > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) > > at java.lang.Thread.run(Thread.java:484) > > > > - > > > > java.lang.reflect.InvocationTargetException: > > > javax.xml.transform.TransformerFactoryConfigurationError: > > java.lang.ClassNotFoundException: > > org.apache.xalan.processor.TransformerFactoryImpl > > at > > > javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:1 > > 21) > > at > > > org.apache.fop.apps.TraxInputHandler.getXMLFilter(TraxInputHandler.java:72) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > > org.apache.fop.apps.XSLTInputHandler.getParser(XSLTInputHandler.java:102) > > at FopServlet.renderXML(FopServlet.java:128) > > at FopServlet.doGet(
Re: [REDESIGN] TextLayoutManager whitespace handling
Arved, are you sure about that? It's a bit confusing since the spec (actually it's 7.15.12 not 7.5.12 as I mistakenly wrote last time) says white-space-collapse happens during area building but only talks about adjacent flow objects not at all about areas. Well actually it does. It says that the collapsed space doesn't "generate an area". I thought only the "suppress-at-line-break" (7.16.3) was actually based on areas. I agree about the definition of ajacent areas (4.2.5) and I don't believe there is a clear definition of ajacent FO, so maybe it's best to follow your interpretation. In fact, my white-space-collapse code in the new Fop is currently collapsing them during FO tree construction (== refinement) after doing the white-space and linefeed handling. So if it's supposed to deal with areas it's not right. -Karen Arved Sandstrom wrote: > > I should add, if the 2 spaces end up on the same line, of course. Until we > do layout we don't know. > > -Original Message- > From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] > Sent: February 28, 2002 7:03 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [REDESIGN] TextLayoutManager whitespace handling > > Comments below. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Karen Lease > Sent: February 28, 2002 6:31 PM > To: [EMAIL PROTECTED] > Subject: Re: [REDESIGN] TextLayoutManager whitespace handling > > [ SNIP ] > > That's one thing. In your example, even supposing we are doing > white-space collapse, the issue is which one gets thrown out. In 7.5.12 > (white-space-collapse), the spec says: ".. [if] the immediately > preceding flow object is a character flow object with a character > classified as white space in XML ... that flow object shall not generate > an area." > > So if we think that the the space after "text" and the one before "more" > are adjacent, which is strictly speaking not the case, I'd say the one > before "more" disappears. If we aren't collapsing or we decide that the > intervening newline makes them not adjacent, there are two spaces and > the second is underlined. > > -Karen > > Keiron Liddle wrote: > > > > Hi Karen, > > > > I seem to be having a bit of trouble getting that text parsing right. I > > was mainly just trying to get something to work to see on the output. > > It should be able to be simplified thanks to the earlöier whitespace > > handling. > > I still wonder what should be done in a situation like: > > some text more > > text > > Is the space before "more" underlined or not? > > Pursuant to my earlier post on this question, I think we are all agreed that > "score-spaces" dictates whether or not the space immediately preceding the > word "more" in the example gets underlined or not, _assuming_ that that > space survives. > > As Karen points out, initial value for "white-space-collapse" will make the > second space go away (leastways I concur in that interpretation). Adjacency > is based on whether or not the 2 areas have a block- or > inline-stacking-constraint, and the two spaces in question have an > inline-stacking-constraint by 3a in Inline Stacking Constraints, Section > 4.2.5, so are adjacent. > > Regards, > AHS > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Understanding] Property Handling [5]
Hmm, good question. How is "punt" for an answer? Seriously, that's probably another case of delayed evaluation. Though I think the issue concerns the descendants of "marker" and not the properties on "marker" itself which are said to be ignored. This is certainly not handled correctly as it stands. I really hate those cases where property evaluation depends on where the stuff is laid out. -Karen "Peter B. West" wrote: > > Karen, > > Thanks for this detailed info. What do you do about "ems" lengths in a > marker? > > Peter > > [EMAIL PROTECTED] wrote: > > > Expressions involving "em" units which are relative to > >font-size _are_ resolved during the FO tree building however. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] TextLayoutManager whitespace handling
Hi Kerion, I agree it's better to have some output. Like my choir director says, we can't know if you're singing the wrong note if we can't hear it :-) I had some code written for this, but it's set up to return a BreakPosition and it's incomplete. I haven't gone back to the white-space handling code in a couple of months, but I remember that after I had written it, I went through some soul-searching about what should be done about text runs across fo:inline, wrappers etc. I actually wrote to the xsl-editors about this. 1a. white-space-treatement: the values which ignore whitespace before, after or surrounding a linefeed, use the phrase "any character flow object ... whose character is classified ... as white space in XML (or any sequence of such character flow objects) that immediately precedes/follows a character flow object whose Unicode code point ... is U+000A". By immediately preceding (or following) is it your intention that the sequence of character FOs in question are siblings, or that they are adjacent in a traversal of character FO leaves? In the first (literal) interpretation, in the following example the spaces after "abc" will not be ignored, because the following linefeed is in the wrapper and not an immediate sibling. Text abc abc xxx .. 1b. white-space-collapse: same question for the "true" value concerning collapse of immediately preceding/following or "consecutive". The literal interpretation is certainly easier to implement. If I use the "leaf-node" interpretation (ie, what is visible on the paper), there are some fuzzy cases where the value of the property can change in the middle of a sequence of white-space, which makes it hard to know what shold be done. On the other hand, in the case of fo:wrapper which is often used simply to change the font-style or weight, it seems logical that white-space handling should transparently cross the boundary. That's one thing. In your example, even supposing we are doing white-space collapse, the issue is which one gets thrown out. In 7.5.12 (white-space-collapse), the spec says: ".. [if] the immediately preceding flow object is a character flow object with a character classified as white space in XML ... that flow object shall not generate an area." So if we think that the the space after "text" and the one before "more" are adjacent, which is strictly speaking not the case, I'd say the one before "more" disappears. If we aren't collapsing or we decide that the intervening newline makes them not adjacent, there are two spaces and the second is underlined. -Karen Keiron Liddle wrote: > > Hi Karen, > > I seem to be having a bit of trouble getting that text parsing right. I > was mainly just trying to get something to work to see on the output. > It should be able to be simplified thanks to the earlöier whitespace > handling. > I still wonder what should be done in a situation like: > some text more > text > Is the space before "more" underlined or not? > > Keiron. > > On 2002.02.23 18:30 [EMAIL PROTECTED] wrote: > > Keiron, > > > > I see you've actually started to make TextLayoutManager do something. I > > noticed during my CTM testing with the PDF renderer, that it's "eating" > > the first character of my text, ie. "Hello world" came out as "ello > > world". Since I don't think you're French which could account for not > > pronouncing the 'h', I thought it might be due to the 'wordStart + 1' > > used to set the text for the Word Area. > > > > I also noticed there's a lot of whitespace handling in the code still. A > > few months ago I put some white-space handling into the FO tree building > > logic. In fo.flow.Block.end(), it basically iterates over all its kids > > and tries to get rid of all the unnecessary white-space before it gets > > to the layout manager. > > The idea was that the LM would only see the whitespace it was actually > > supposed to layout and the linefeeds which were real line-break > > characters. > > > > I haven't studied the new TextLM code in detail, but I would think it > > could be simplified based on that approach. > > > > Regards, > > Karen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: column-width as em
Hi Joseph,
I think it will work if you set a width on your table. Try width="100%".
The message is a little obscure: it means the number of millipoints
(1/1000ths of points) which is the sum of your column widths is greater
than the specified inline-progression-dimension which isn't set to
anything.
You might also try setting all of the column-widths to one proportional
unit using column-width="proportional-column-width(1)". That should make
sure that all your columns are included, whatever the width is. You must
still set the width on the table though.
Good luck,
Karen Lease
[EMAIL PROTECTED] wrote:
>
> Howdy,
>
> I'm using the fop-0_20_2-maintain code from CVS
> (still up to date as of today).
>
> When I use:
>
>
> />
> />
>
>
> I get an warning message that
> "Sum of fixed column widths 1512000 greater than maximum specified IPD 0"
>
> 1512000 is 12000 times the sum of my width attributes. The PDF display
> includes
> only the first five of my ten columns, and the columns are much wider than
> I expect.
>
> I set the width attributes in a servlet reading from a database.
> (resMetaD is ResultSetMetaData from my query.)
>
> width = resMetaD.getColumnDisplaySize(i);
>
> if (resMetaD.getColumnLabel(i) != null) {
> label = resMetaD.getColumnLabel(i);
> } else {
> label = resMetaD.getColumnName(i);
> }
>
> if (width < label.length()) {
> width = label.length();
> }
>
> width=width+3;
>
> I output the width values as I create Attribute objects for them in the
> servlet. That's
> how I know my total should be 126.
>
> Am I using the em unit incorrectly? I thought by setting column widths a
> bit bigger than
> the likely maximum length in the column I could fit more columns in a
> table.
>
> Thanks,
>
> Joe
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: FOP conformance
I'm glad to see this will be getting done. I had thought of doing it, but I'm trying not to get distracted and to devote what little time I have (which is likely not to improve for the next two weeks unfortunately) to the new FOP. Since I'm going to be talking about XSL-FO at the XML 2001 conference in 10 days, I would have been a bit unhappy to admit that there is no version of FOP which handles the final XSL recommendation syntax. I think there are a few bug fixes and table improvements in the current maintenance branch which I committed just after 0-20.2-RC was out, and which may help some FOP users. I've also seen some recent complaints about Fop's famous looping behavior when any object won't fit on the page, including a set of spanned table rows. I think it would at least be worthwhile trying to make a set of spanning rows breakable. If Arved, Christian or someone else could look at this, I'd be happy to give a few pointers. Regards, Karen Arved Sandstrom wrote: > > And between me and Christian I think we will see to it that this change, at > least, gets done and is reflected in a maintenance release, which I suggest > should appear NLT Dec 15. > > In other words, I accept your argument (that was never in question). It's a > resource thing...Keiron and Karen (and some others, such as Peter West) are > looking at the rewrite, so it's up to the rest of us to do stuff like this. > > AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Some white-space issues
Hello XSL editors, I've got a few questions relative to the various white-space related properties in XSL which perhaps you could clarify. 1a. white-space-treatement: the values which ignore whitespace before, after or surrounding a linefeed, use the phrase "any character flow object ... whose character is classified ... as white space in XML (or any sequence of such character flow objects) that immediately precedes/follows a character flow object whose Unicode code point ... is U+000A". By immediately preceding (or following) is it your intention that the sequence of character FOs in question are siblings, or that they are adjacent in a traversal of character FO leaves? In the first (literal) interpretation, in the following example the spaces after "abc" will not be ignored, because the following linefeed is in the wrapper and not an immediate sibling. Text abc abc xxx .. 1b. white-space-collapse: same question for the "true" value concerning collapse of immediately preceding/following or "consecutive". The literal interpretation is certainly easier to implement. If I use the "leaf-node" interpretation (ie, what is visible on the paper), there are some fuzzy cases where the value of the property can change in the middle of a sequence of white-space, which makes it hard to know what shold be done. On the other hand, in the case of fo:wrapper which is often used simply to change the font-style or weight, it seems logical that white-space handling should transparently cross the boundary. 2. suppress-at-line-break: the initial value of the property is "auto", which means that character FOs with a code point of U+0020 (space) are treated as if the value were "suppress". I take it that this means that the following fo example, with the default values for white-space-treatment and linefeed-treatment : (0xa) some text.(0xa) will _not_ generate a space before the "s" of "some text", nor at the end. On the other hand, using white-space-treatment="preserve", linefeed-treatment="preserve" and white-space-collapse="false", the leading spaces are not suppressed because they are not "formatter-generated". Seems reasonable to me. Thanks in advance, Karen Lease [EMAIL PROTECTED] Senior Software Developer/SPX Valley Forge FOPper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: font-family default?
The overall default is the generic family "sans-serif". For PDF, that's probably Helvetica. The default size is 12pt. bryan hansen wrote: > > If you don't specify a font-family, what is the > default font that is used? I have searched around the > site and it doesn't appear to be listed anywhere that > i can see. > > I specify in certain areas what font to use, but > nothing for the overall pdf. > > __ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Graphic repeats in FOP multi-page table
Hi Jaron,
I discovered this problem and found a fix for it just before 0.20.2RC
was released. So it's in CVS, in the "maintenance" branch, CVS tag
"fop-0_20_2-maintain". You could get the 0.20.2RC source distribution
(same place you downloaded the binary), apply the attached patch to
src/org/apache/fop/fo/flow/TableCell.java and rebuild.
Or you could get the source file out of CVS, using the web interface:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/fo/flow/TableCell.java?only_with_tag=fop-0_20_2-maintain
Or you could try just sticking the attached class file on your path
before the fop.jar in the binary build. Maybe that will work.
Good luck,
Karen Lease
"Jaron J. Rubenstein" wrote:
>
> FOPers,
>
> I have been working through an odd XSL-FO for the past few days. I would
> truly appreciate some assistance in getting this to work (or at least
> confirming that it's a bug). I'm using FOP 0.20.2RC from the binary Linux
> distribution.
>
> I have a simple table that sets the formatting for my document. The table
> looks like:
>
> +---+-+---+ Legend:
> | A |B| C | A: empty cell
> +---+-+---+ B: empty cell (for spacing)
> | D |E| F | C: headline (text)
> | | | | D: image (fo:external-image)
> | | | | E: empty cell (for spacing)
> +---+-+---+ F: lots of text (spans multiple pages)
>
> The table spans multiple pages because cell F contains a lot of text. The
> image in cell C is a basic fo:external-image wrapped in an fo:block. The
> full xsl:fo code for this (in simplified form) is at the end of this
> e-mail.
>
> Now, for some reason unbeknownst to me, the image in cell D repeats itself
> in the same column on the second and subsequent pages. That is, the image
> is displayed at the top of cell D on page 1, but it is also displayed at
> the top of that 'column' on pages 2, 3, etc. This happens with any images
> (and multiple images) that are in that cell, but not text. I tried a
> number of solutions, some worked but had nasty side-effects (see the
> comments in the code below).
>
> My questions:
>
> 1. Is this supposed to be happening, or this a bug in the FOPlayout
> engine?
>
> 2. How can I fix this?
>
> I'm hoping that somebody can shed some light on this for me. I've searched
> books, the archives, and the Web, and can't seem to find any answers. I've
> tried numerous solutions, none of which seem to work. At this point, I'm
> either going to start pouring through Java FOP code, or give up. Any
> pointers in the right direction are very much appreciated!
>
> Thanks in advance,
>
> -Jaron
>
> --
> Jaron Rubenstein, Logicept
> [EMAIL PROTECTED]
> www.logicept.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
*** TableCell.java.0_20_2RC Sat Sep 29 21:28:30 2001
--- TableCell.java Wed Nov 21 00:14:53 2001
***
*** 82,87
--- 82,92
// boolean setup = false;
boolean bSepBorders = true;
+
+ /**
+ * Set to true if all content completely laid out.
+ */
+ boolean bDone=false;
/**
* Border separation value in the block-progression dimension.
***
*** 209,214
--- 214,220
area.getIDReferences().createID(id);
this.marker = 0;
+ this.bDone=false;
}
/*
***
*** 250,256
cellArea.setTableCellXOffset(startOffset);
int numChildren = this.children.size();
! for (int i = this.marker; i < numChildren; i++) {
FObj fo = (FObj)children.elementAt(i);
fo.setIsInTableCell();
fo.forceWidth(width);// ???
--- 256,262
cellArea.setTableCellXOffset(startOffset);
int numChildren = this.children.size();
! for (int i = this.marker; bDone==false && i < numChildren; i++) {
FObj fo = (FObj)children.elementAt(i);
fo.setIsInTableCell();
fo.forceWidth(width);// ???
***
*** 275,280
--- 281,287
area.setMaxHeight(area.getMaxHeight() - spaceLeft
+ this.cellArea.getMaxHeight());
}
+ this.bDone=true;
cellArea.end();
area.addChild(cellArea);
TableCell.class
Description: Binary data
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Support for large row spanning
Hi Paul,
This kind of problem, like many others involving page breaking
decisions, will be addressed in the rewritten version of FOP which some
of us (most Keiron Liddle) are currently working on. I know it's
frustrating not to see any forward evolution during this time, but we
felt FOP had gotton to a point where it was too difficult to handle this
kind of problem. The timescale for the redesigned FOP being able to
handle that correctly is a minimum of several months. So unfortunately,
I think you have two choices:
1. use your workaround,
2. if you're feeling brave, look at the FOP CVS branch which is the
"bug-fix" branch, which should still be in working order and try to work
out a way to make the spanning rows "breakable". You may be able to get
something that works for you. In org/apache/fop/fo/flow/TableRow.java,
in the layout() method, you'll see some code like this:
if ((status = cell.layout(areaContainer)).isIncomplete()) {
if ((keepTogether.getType() == KeepValue.KEEP_WITH_ALWAYS)
|| (status.getCode() == Status.AREA_FULL_NONE)
|| rowSpan > 1) {
This means: if the current cell doesn't completely fit on the current
page, and if the row is suposed to always be "kept-together" or nothing
at all fit in the cell or we are in a row-spanning cell, we give up
trying to layout this row and try again on the next page.
Obviously, if this is the first row on the page already, we should just
"break" it anyway and put the rest of the cell on the next page. Fop
knows how to do this for non-spanning cells (well, actually, it doesn't
check to see if this is the first row on the page), but I was being lazy
when I wrote the spanning code and didn't do this. If you just get rid
of the (rowSpan>1) condition, that probably won't completely solve it,
but you could start from there and then try to fix what didn't work.
Or perhaps if you sent me some good chocolate, you could convince me to
divert my attention from the redesign and try to figure out a fix for
this. :-)))
Seriously, if it's a blocking problem, I could be convinced. I know
you're not the only one inconvenienced by this.
Or perhaps one of the other FOP committers could be convinced to look
into this. Takers anyone?
Best regards,
Karen Lease
"Smith, Paul" wrote:
>
> In Fop 0.20.2 if a table cell spans more rows than fit on a page it loops
> infinitely, presumably trying to find a page big enough to place the cell
> on. Looking through the archives of this list I found that I am not the only
> one who has been affected by this. David S. Dixon reported it as a problem
> on 21/9/01. At that time Karen Lease said that she was looking at this
> problem. So what is this current situation? Is it a priority to fix this
> bug? If so what sort of timescale are we looking at?
>
> I can write a work around (although it will be messy) in my application but
> it would be nice to have a proper fix in FOP. I will take a look at the FOP
> code but as I am new to FOP any pointers on where to look and ideas of how
> this problem maybe solved would be much appreciated.
>
> I have included the original thread below. Taken from
> http://marc.theaimsgroup.com/?l=fop-dev&m=100117495412259&w=2
>
> ---
> Paul Smith
>
> Karen,
>
> That's it -- thre spanning column has a long list-block that goes over to
> the next
> page. Okay, I can workaround by putting tables within tables. Thanks.
>
> -dd
>
> Karen Lease wrote:
>
> > David,
> >
> > I don't think it was in 0.19.0, which is consistent with the error
> > message.
> > The reason for the infinite loop may well be that some group of rows
> > which are held together by spans is too big to fit on the page. This is
> > a known bug, and I'm not currently working on it, as it's not that easy
> > to do. Like many difficult layout issues, we hope to attack this in the
> > "redesign".
> > However, just to make sure that there isn't some other wierd reason for
> > this problem, I'd be happy to look at your .fo file.
> >
> > Regards,
> > Karen
> >
> > "David S. Dixon" wrote:
> > >
> > > Karen,
> > >
> > > Was number-rows-spanned support in 0.19.0? I have an .fo file that
> turns into a
> > > .pdf file under 0.19.0 but complains of
> > >
> > > WARNING: Number of cell columns under table-row not equal to number of
> > > table-columns
> > >
> > > for the two rows corresponding to the spanned rows. Under 0.20.1, fop
> goes into
> > > an infinite loop on this file.
> > >
> > > -dd
> > >
> > > Karen Le
Re: [REDESIGN] Initial cut at Layout Manager
Hi Keiron, I'm pretty sure all the various details are not quite correct, but I agree that the best way to find out is to try to actually use it and then we'll figure out what to change. I've started to think about the character level, but I'm short on time for the next week. Also mulling over the Property/Trait handling. Concerning your question, it's one I've already thought about. I think that yes, it should be possible to run the FO tree building and the layout process in parallel. That's one of the reasons the layout is designed to run in a thread. I think it can wait on the flow tree events via the iterator over the children (in generateAreas). The iterator can wait to see if there is a new child available. When an FO node is completed its "end()" method gets invoked by the FOTreeBuilder. It can then be marked as complete so the iterator will know when it's not worth waiting for any more children to be added. I think using that scheme, we can start layout as soon as the flow has some block level child, even if that child is not yet finished. Of course, some kinds of FO need to have more children before doing layout. For example, it makes no sense to start laying out a table until at least all the columns have been seen to calculate column widths. Regards, Karen Keiron Liddle wrote: > > Hi Karen, > > Thanks for the contributions. > I have had a look and I think it is along the right track. It is a bit hard > to know if all the various details are correct. The only way to determine > if it will eventually work is to gradually build it up and see that it is > working for us. > > One question I think we should consider and tackle if possible at this > stage is: > Is it possible to layout blocks as soon as possible and generate a page > once blocks have filled a page. > That is, the driving events are the starting and ending of elements in the > sax events. When a block level object is finished directly under the flow > level then can we add this block to the current page. Once the page is full > (or page break) then we finish the layout of the page then send it on to > the render. Then the completed fo elements that made up the page can be > discarded. > Rather than always waiting for a page sequence to end, which is easier but > not better. > > Regards, > Keiron. > > On 2001.11.10 00:05 Karen Lease wrote: > > Hi all, > > An initial version of the Layout Manager classes (package > > org.apache.fop.layoutmgr) is now in CVS, plus some related changes in > > Area (up for discussion; this is just past the pseudocode point, but at > > least it builds :-) and in the fo/pagination classes. > > Needless to say, it does nothing useful whatsoever yet. > > > > Regards, > > Karen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Initial cut at Layout Manager
Hi Arved, Nice to hear from you again. As you can see Keiron is doing most of the work, so he probably has some ideas for you. From my point of view, if you could look a bit at the LayoutManger classes (I've put a couple more in there) and the interfaces I'm starting to define with the Area classes, and make some comments it would help. The LayoutManager interface is still pretty simple. There are a few things bothering me though and I'd appreciate your feedback. One question is how much intelligence to put in the Area classes themselves and how much in the LayoutManagers which are creating them. For example, does the Area know how to calculate its own IPD and BPD when child areas are added, or does the LM tell it this? In the old scheme, the FO set dimensions on the Areas (in general). I always thought the Area classes should have done it. But now that we've moved layout intelligence into the LM classes, maybe its logical that they do the fancy calculations and set the results on the Area. I think we also need some input on Property (ie. trait) management on the areas (or on the LM?). Keiron has started to specify some interfaces. Also maybe we need to look at the class hierarchy some. I've already noticed I'm doing a bunch of "casting" in the LM code, which isn't usually a good sign. My short-term goal is to get just enough LM code in place to get a feel for how it should work and to stabilize interfaces with the Area classes. I don't want to attack the more complicated cases yet, though I've got some ideas for float management in the back of my mind. Regards, Karen Arved Sandstrom wrote: > > At 12:05 AM 11/10/01 +0100, Karen Lease wrote: > >Hi all, > >An initial version of the Layout Manager classes (package > >org.apache.fop.layoutmgr) is now in CVS, plus some related changes in > >Area (up for discussion; this is just past the pseudocode point, but at > >least it builds :-) and in the fo/pagination classes. > >Needless to say, it does nothing useful whatsoever yet. > > All I can say is that I'm grateful that the two of you, Keiron and yourself, > have the time to do this. I've been tracking progress, and basically I am > waiting for the right moment to jump in and help out with smaller bits, > because I can squeeze out time for that...just not the bigger stuff. I guess > what I'm asking is, is there any area in particular that I can assist with > or should take a look at? > > Regards, > Arved > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[REDESIGN] Initial cut at Layout Manager
Hi all, An initial version of the Layout Manager classes (package org.apache.fop.layoutmgr) is now in CVS, plus some related changes in Area (up for discussion; this is just past the pseudocode point, but at least it builds :-) and in the fo/pagination classes. Needless to say, it does nothing useful whatsoever yet. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] area tree
Hi Keiron, Looking forward to your commit. So then "all we have to do" is make the FO + layout managers create the new Areas. I have gone back into design mode and have lots of pieces of paper covered with pseudocode and diagrams, concerning area creation. It's a lot longer to put the diagrams into UML though... Maybe easier just to try writing some code. I was thinking of the minimal set to start with: PageSequence, Block, Text. If we get the basics of inline layout right: line-breaking, line-stacking, it will give us a solid basis for adding the rest of the inline objects. Karen Keiron Liddle wrote: > > On 2001.10.19 23:48 Karen Lease wrote: > > Hi Keiron, > > > > I've been a bit submerged this week and didn't respond to your and > > Arved's posts when they went by. > > > > I think tables now have enough functionality to satisfy most users. But > > thinking about how to do the "auto" layout got me back into pondering > > about inline area layout. > > > > Where and how are you planning to start on your changes? Is there some > > way I can collaborate by working on inline stuff or is that what you are > > working on? (which would be logical I suppose). > > > > Regards, > > Karen > > Hi Karen, > > How about I commit the stuff soon. As suggested by Arved, create a branch > for current code maintainence and do everything in the main branch. > All I have really done so far is to create a set of area tree classes (in > package org.apache.fop.area) and changed the renderers to use the new > classes. The renderers are currently almost empty of code, I wanted to > start from the top. > The rest of fop is left as is. It will still create the old area tree but > of course the renderers are not connected so you will get no output. > The new area tree attempts to be what the spec says with the minimal amount > of information and classes (I would still like to make it smaller though). > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: entity_keys.xml
Your question is a little vague. The general answer is: write an XSL stylesheet which transforms your intput entity_keys.xml document into elements in the FO (XSL Formatting objects) namespace and use FOP or some other FO processor to produce PDF. The transformation depends on what you want your output to look like. In other words, for each element in your input XML vocabulary, what kind of printed representation is appropriate? You probably need to look at some general XSL-FO resources to get a better handle on how to do that. Try starting here: http://xml.apache.org/fop/resources.html and look at the Tutorials/Articles section. Good luck, Karen Lease "Rossi, Bernard L. (LNG)" wrote: > > How would you transform something like this to pdf? > <> > > Thanks. > Bernie Rossi > > Name: entity_keys.xml >entity_keys.xmlType: unspecified type (application/octet-stream) > Encoding: x-uuencode > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Unknown header extent?
Matt, The short answer is "no". The value must be specified as a fixed length or as a percentage which is interpreted relative to the page height, so it's still a fixed value. So your options are: 1) make extent large enough to contain your biggest possible header 2) depending on the structure of your documents, put the entire document into an fo:table and put the header part into the fo:table-header. Regards, Karen Matt Savino wrote: > > Is there any to avoid explicitly setting the extent of header > (region-before)? I have a report that requires a varied number of data > rows and possibly a comment field of unknown size within the header. > I've looked through the examples, but all of them seem to have the > header size hard-coded. > > Thanks a lot, > Matt > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fwd: hyphenate
Daniel, There are a few people who have dealt with hyphenation in the past, but they are not very active currently. I do see some code dealing with hyphenation at the text level which is commented out. I suspect that may be because it didn't quite work as planned. If you would submit this as a bug to bugzilla, we will keep being reminded of it and hopefully address it. We are planning some major rewriting of the layout code, including inline objects, so we'll try to make sure this works as part of that. Sorry I can't promise any faster action. Regards, Karen Lease > > ..I sent this a few days ago but didn't get an answer. > Is there really nobody who stays in touch with these > features? > > daniel > > --- Daniel Pfuhl <[EMAIL PROTECTED]> schrieb: > Datum: > Thu, 18 Oct 2001 18:33:56 +0200 (CEST) > > Von: Daniel Pfuhl <[EMAIL PROTECTED]> > > Antwort-an-Adresse: [EMAIL PROTECTED] > > Betreff: hyphenate > > An: fop-list <[EMAIL PROTECTED]> > > > > Hi, > > > > I am using the CVS version of FOP from last week. > > I defined a block for my text as follows: > > > > > font-size="10pt" > > font-weight="normal" > > space-before="1mm" > > space-after="1mm" > > text-align="justify" > > language="de" > > hyphenate="true" > > > > > > > inside this block I sometimes use an inline > > object for tagging phrases wich should not be > > hyphenated. this inline object looks like this: > > > > > language="de" > > hyphenate="false" > > > > > > > nevertheless the so tagged words also will be > > hyphenated. I think in older versions this > > feature worked. Maybe the syntax changed? > > > > Any ideas ?? > > > > thanx > > > > daniel > > > > = > > > > > Daniel Pfuhl > > mailto:[EMAIL PROTECTED] > > > > > __ > > > > Es ist soweit: das Nokia Game beginnt. Sei bereit > > für das multimediale Abenteuer. Melde dich bis zum > > 3. November bei > > http://de.promotions.yahoo.com/info/nokiagame an! > > > > = > > Daniel Pfuhl > mailto:[EMAIL PROTECTED] > > __ > > Es ist soweit: das Nokia Game beginnt. Sei bereit für das multimediale Abenteuer. >Melde dich bis zum 3. November bei http://de.promotions.yahoo.com/info/nokiagame an! > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: xalan version
Bonsoir Guillaume, I'm not much of an expert on batik (vast understatement :-). I know there are some compatibility issues. I see that Keiron Liddle (who IS a batik expert) recently put a new version of batik.jar into the FOP lib directory. Maybe you should try using that instead of the standard batik 1.0 jar. You can get it at http://cvs.apache.org/viewcvs.cgi/xml-fop/lib/. You said in a previous mail that you were not building with the fop jars but with the latest (CVS?) versions of the various fop dependencies. That's pretty much what Apache GUMP project is doing and its current build of FOP using latest versions of all dependencies is OK. You might want to look at http://jakarta.apache.org/builds/gump/latest/xml-fop.html for information. In short I guess I'd recommend either sticking to the jars supplied with the FOP distribution, or using the CVS version of Fop with your newer jars. Although I haven't tried compiling 0.20.2RC from the distribution, I don't have any trouble with the current CVS version of fop, using the jars in the xml-fop/lib directory. I can also build the CVS using the 2.2.D9 version of xalan.jar. Good luck, Karen Guillaume Rousse wrote: > > Ainsi parlait Karen Lease : > > I committed into CVS 26.8.2001. So it wasn't in 0.20.1 but it should > > certainly be in 0.20.2RC. > However, 0.20.2RC compilations fails with current batik 1.0 release: > [javac] > /home/guillaume/rpm/BUILD/Fop-0.20.2/build/src/org/apache/fop/svg/PDFANode.java:55: > paint(java.awt.Graphics2D,org.apache.batik.gvt.GraphicsNodeRenderContext) in > org.apache.batik.gvt.AbstractGraphicsNode cannot be applied to > (java.awt.Graphics2D) > [javac] super.paint(g2d); > I attempted to back port the patch to 0.20.1 by using the build.xml 1.42-1.43 > diff (matching given date), but that is is not enough, the third xslt process > still fails: > codegen: > [echo] Resetting codegen directory > [copy] Copying 35 files to > /home/guillaume/rpm/BUILD/Fop-0.20.1/build/src/codegen > [echo] Generating the java files from xml resources > [xslt] > [xslt] xslt > [xslt] in: ./build/src/codegen/svgelements.xml > [xslt] style: ./src/codegen/propmaker.xsl > [xslt] out: ./build/src/codegen/svgproperties.xml > [xslt] > [xslt] > [xslt] xslt > [xslt] in: ./build/src/codegen/allprops.xml > [xslt] style: ./build/src/codegen/genconst.xsl > [xslt] out: ./build/src/org/apache/fop/fo/properties/Constants.java > [xslt] > [xslt] org.apache.xml.utils.WrappedRuntimeException: > /home/guillaume/rpm/BUILD/Fop-0.20.1/foproperties.xml (Aucun fichier ou > répertoire de ce type) > [..] > [xslt] > file:/home/guillaume/rpm/BUILD/Fop-0.20.1/./build/src/codegen/genconst.xsl; > Line 9; Column -1; Can not load requested doc: > /home/guillaume/rpm/BUILD/Fop-0.20.1/foproperties.xml (Aucun fichier ou > répertoire de ce type) > > I also check other concerned files (foproperties.xml, properties.xsl), but i > didn't found any relevant commit. > > I think i'd better wait for batik 1.1 and fop 0.20.2 final release. > -- > Guillaume Rousse <[EMAIL PROTECTED]> > GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] area tree
Hi Keiron, I've been a bit submerged this week and didn't respond to your and Arved's posts when they went by. I think tables now have enough functionality to satisfy most users. But thinking about how to do the "auto" layout got me back into pondering about inline area layout. Where and how are you planning to start on your changes? Is there some way I can collaborate by working on inline stuff or is that what you are working on? (which would be logical I suppose). Regards, Karen Keiron Liddle wrote: > > Hi All, > > So far I have only got a basic view of the area tree. I think the best way > to deal with changes from this direction is to build the area tree and then > change the renderers to handle the new area tree. This includes things like > viewports. > This will take some time it seems, then we need to look at making the > layout engine create the areas. > > This may be done in a branch? > > There are some things that I'm still not sure how to handle or what is the > best way. > eg. inline level properties, background images for inline areas (groups), > placement of table and list child areas in terms of area model. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: xalan version
I committed into CVS 26.8.2001. So it wasn't in 0.20.1 but it should certainly be in 0.20.2RC. Guillaume Rousse wrote: > > Ainsi parlait Karen Lease : > > That sounds kind of familiar. > > A while back, FOP was failing with GUMP builds which use the CVS version > > of xalan because of relative URLs in the document() function, for > > example in genconst.xsl. At the time I made some changes in the Fop Xslt > > task which fixed that problem. So I'm not sure why you're seeing it. > > I'll try to look into it again. > Has the change been commited only in current CVS, or was it included in > 0.20.1 release ? > Also, note i don't use any of the jars archive shipped with fop, but > self-build corresponding current applications versions. > -- > Guillaume Rousse <[EMAIL PROTECTED]> > GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Invalid Image URL - error on relative URL : no protocol
Actually, a relative URL shouldn't specify a protocol. It gets it from the protocol of the "base" URL, usually the URL of the document containing the relative reference. That way it should work using both file: and http: for example. Also use forward slashes in URLs even on Windows: "../graphics/some.gif". Regards, Karen Ursprung Manfred wrote: > > That's nice for absolute path. > How do yo do it on relative path ? > Like: > file:..\graphics\some.gif > it doesn't work. > > Thats the trick ? > -Manfred > > > -Ursprüngliche Nachricht- > > Von: Amit [SMTP:[EMAIL PROTECTED]] > > Gesendet am: Mittwoch, 10. Oktober 2001 20:03 > > An: [EMAIL PROTECTED] > > Betreff: Re: Invalid Image URL - error on relative URL : no protocol > > > > If on Windows do this: > > > > file:C:\path\some.gif > > > > If on Unix like OS do this > > > > file:///www/images/some.gif > > > > > > Amit > > > > MEMMADI Said wrote: > > > > > Hi all, > > > > > > I have the folowing error with fop 0.20.1 > > > > > > Error while creating area : Invalid Image URL - error on relative URL : > > no protocol: > > > null./images/mypicture.png > > > > > > In my xsl file : > > > or > > > > > > > > > Thanks in advance. > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: xalan version
That sounds kind of familiar. A while back, FOP was failing with GUMP builds which use the CVS version of xalan because of relative URLs in the document() function, for example in genconst.xsl. At the time I made some changes in the Fop Xslt task which fixed that problem. So I'm not sure why you're seeing it. I'll try to look into it again. Regards, Karen Lease Guillaume Rousse wrote: > > Sorry if this has already been asked there, but list archive are currently > unreachable. > > The current fop version (0.20.1) ships with xalan-j 2.0.0, and builds fine. > Trying to build it with current xalan-j 2.2.D11 fails with those error > messages: > [xslt] org.apache.xml.utils.WrappedRuntimeException: > /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire > de ce type) > [..] > file:/home/guillaume/tmp/Fop-0.20.1/./build/src/codegen/genconst.xsl; Line 9; > Column -1; Can not load requested doc: > /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire > de ce type) > [xslt] org.apache.xml.utils.WrappedRuntimeException: > /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire > de ce type) >[..] > file:/home/guillaume/tmp/Fop-0.20.1/./build/src/codegen/genconst.xsl; Line 9; > Column -1; Can not load requested doc: > /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire > de ce type) > > Is this a known error, and if so, is there a workaround ? > Thanks > -- > Guillaume Rousse <[EMAIL PROTECTED]> > GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: padding in table-row
Well, no, actually the XSL Recommendantion says that padding doesn't apply to table-row (See 6.7.9 and the "Note" about Common Border, Padding and Background properties. Using padding on table-cell is the correct solution. Regards, Karen Keen Tim wrote: > > I'm attempting to use padding-top and padding-bottom to put some space > between rows of a table. These attributes don't seem to be working in > table-row, but the desired result can be achieved using padding in > table-cell. > > I think this might be a bug and would just like to make whoever needs to > know aware. > > Cheers > > Tim > > > The information in this e-mail together with any attachments is > intended only for the person or entity to which it is addressed > and may contain confidential and/or privileged material. > > Any form of review, disclosure, modification, distribution > and/or publication of this e-mail message is prohibited. > > If you have received this message in error, you are asked to > inform the sender as quickly as possible and delete this message > and any copies of this message from your computer and/or your > computer system network. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Layout with Page Breaks (re-visited)
Hi Chris, Yes, definitely try a more recent version. The latest is actually 0.20.2. That should have support for setting height on either row or cell and maybe some sizing problems have been fixed. To prevent rows being broken, use keep-together="always" on the table-row object. That's the only object in FOP where keep-together works. Also check the relation between the "extent" attribute on your before and after regions and top and bottom margins on your body region to make sure the body doesn't overlap the after region. HTH, Karen > "West, Chris" wrote: > > I previously made a posting regarding this topic and received some > helpful responses. However, I'm still having the problem. This time, > I'll describe the problem in greater detail. > > I use FOP to dynamically create a table from database data. The > resulting table can range from just a few rows to many rows, requiring > multiple pages to display the table. The problem I'm having is that a > multi-page table doesn't gracefully traverse the page boundaries. The > table can continue past the page number to the very bottom of the > page, with sometimes only half of the last row appearing on the first > page, with the remaining table being displayed on the next page. I've > tried "keep-with-next", plus other attributes, but haven't had any > success at resolving this issue. > > I've made sure that all table tags are nested under the > "xsl-region-body" tag, as suggested by John T. > > Perhaps part of my problem is that the text in one of the columns is > wrapped onto three lines, as the column width is not sufficient for > all of the text to fit on one line. I'm thinking that perhaps FOP > can't set up the page breaks properly as a result (which is simply a > guess). > > I'm added some logic in my XSL file to end the table and start a new > table every x number of rows (by using the mod() method). However, I > need to be able to set the cell height for this to consistently work > (as the number of rows in a cell could vary). I tried setting height > from the row tag as well as from the cell tag, but the requested > height is being ignored. > > I've been using version 0.19.0. Today, I'm going to try 0.20.1 to see > if there is a difference. > > Any help or suggestion would be greatly appreciated > > Chris W. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
I think anything we can do to encourage the use of XSL-FO is a "good thing", especially now that XSL is finally a W3C Recommendation. +1 Regards, Karen Lease Stefano Mazzocchi wrote: > > Hi people, > > recently, some code was donated to the Apache Cocoon project in order to > connect it with JFor (www.jfor.org) which is a FO->RTF processor. > > It appeared evident to me (and to others, as I discovered later) that > jfor and FOP are doing different things but could be an advantage for > both jfor developers, jfor users, FOP users and FO visibility in general > to join forces. > > Bertrand, here attached, is the main developer behind the project and he > already agreed on donating the code to the ASF. > > IMO, rather than creating another project, it would be best to merge > jfor code with FOP to allow yet another (and widely used) binary format > to render FO in. > Technical details are not that important at the moment, but Bertrand > already stated his flexibility in reshaping jfor code in order to make > it easier/cleaner/more-manageable the merging. > > This said, in order for the donation to take place, I'm officially > requesting a vote from the FOP developers community. The Apache XML PMC > is already informed and will accept any position taken by the community. > > So, here it is, please vote on the following question: > > would you like to accept jfor code and give Bertand Delacretaz committer > status in order to perform the merging on the FOP code following the > technical directions that the FOP dev community will find more > appropriate? > > I remind that only people with committer status are entitled to place a > binding vote, but I suggest everybody on this list to express their vote > and, in case of negative vote, explain their reasons so that we can > properly deal with them. > > Thanks to all. > > Stefano. > > P.S. Sorry for the formality, people but this is legal stuff so I'm > required to wear my ASF member hat :) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:block
Hi Pablo, I'm not sure what you mean by "row". If you mean a line of text, the answer is no, at least not like that. You can try using a leader between the text, replacing the leader-length value with what you want. First textSecond text Or using a table row with several cells and put each of your blocks in a cell. HTH, Karen Pablo Iaria wrote: > > Hi all, > How can I do to have several blocks in the same row ? > > Example: > Suposse I have: > > First text > Second text > > And I want to get "First text" and "second text" in the same row. > > > Thanks in advance, > Pablo.- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Headings
Try using "points" (pt). 1pt is 1/72 inch. You can use 0.5 pt for example. -Karen Scott Moore wrote: > > You're right. I misunderstood your message. Even with a > border-width="1px", the border seem kinda large. Is there a way to specify > a smaller width for the gridline? > > Scott > > -Original Message- > From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 15, 2001 2:56 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Table Headings > > I do have cells like that - some have only one line of text, > some have two or more. Since the border is for the cell, > not the inside the cell, it works fine. > > YS > > -Original Message- > From: Scott Moore [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 15, 2001 2:49 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Table Headings > > Have one of the cells wrap text so it grows taller than the other cells. > Then you'll see the problem. > > Scott > > -Original Message- > From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 15, 2001 2:47 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Table Headings > > I put the borders under each cell, and it works fine. > > border-bottom-style="solid"> > > Yuri > > -Original Message- > From: Scott Moore [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 15, 2001 2:37 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Table Headings > > Karen, > > I have another table related question. I'm trying to add gridlines into the > table body by specifying: > > border-width="1px" border-color="black" border-bottom-style="solid" > > on the underneath each cell. This only works if each cell is > the same height. Although the text is all rows start on the same line, the > blocks are only as big as they need to be, thus making the border impossible > to line up per cell, if some cells have to wrap text. > > I've tried putting those attributes on the object, but they > are ignored. Is there a way to make gridlines work for variable height > cells? > > Thanks, > Scott > > -Original Message- > From: Karen Lease [mailto:[EMAIL PROTECTED]] > Sent: Sunday, October 14, 2001 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: Table Headings > > Hi Scott, > > It sounds like you may be putting the background on the block containing > the text. Try putting it on the table-cell itself or even on the row. > > HTH, > Karen > > Scott Moore wrote: > > > > I'm creating tables for FOP that have a black background with white text > in > > the table header. The rest of the table (the data) is inverse, with black > > characters and white background. > > > > If the header text in a column doesn't fit on one line, it will wrap, > which > > is a good thing. The problem is the rest of the headers that don't wrap, > > their black backgrounds stay on one line. Therefore, the whole table > header > > looks uneven and ugly. Here's an example, the # are the black background: > > > > - > > -#Column#1##|#This#is#column| > > - |2##| > > - > > - Table data| blah blah blah| > > - > > > > Are there any settings that can automatically fix this? I've tried using > > "padding-bottom='1em'" for the first column, and that kinda works, but > it's > > still slightly off. The problem is I won't always know which column > > headings wrap because the fonts are user configurable. > > > > Thanks for any help! > > Scott > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Table Improvements
Hi all, I just committed some new table functionality to CVS. You can now do things like . You can mix absolute and proportional units in the same table and even on the same column. See docs/examples/fo/tableunits.fo for some examples. Also, Fop is now looking at the table-layout property. Since it defaults to "auto" and Fop still doesn't do "auto", it will print an annoying warning on every table. That is to remind you to put table-layout="fixed" on your tables! Fop is also using inline-progression-dimension on table instead of width. But don't worry; if you specify width, it will use that as inline-progression-dimension.optimal. Have fun! Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: page cannot be printed
Hi Cristian, If this is the same table you had written about the other day, which gave you some error messages, including: [WARN]: current implementation of tables requires a table-column for each column, indicating column-width it looks like you have a table without table-column objects, or a table-column without any column-width specified. I don't know why DocBook would generate that, but you could try sending your FO file, or the part of it containing the table which fails, to this group. Also, hopefully tonight, I'll commit some new table code which implements the proportional width function for table-columns, so it's easier to specify them. Hope that helps, Karen Lease "Kaiser Christian (SV SC RS T33)" wrote: > > Hello, > > a page that includes a (certain) table cannon be printed. > This table includes only images. > > I've create this document in DocBook XML 5.0 beta. > Xalan to translate it into FO (DocBook XSL Stylesheets > v. 1.44). > I have specified the column-with for each column. > I've also specified the amount of columns in > the attribute "cols" of "informaltable". > > It just stops printing if this page would be on the turn. > I can watch it, but not print. > > Is there a way arround this problem, > or does anybody know what causes it (to fix the bug). > > best regards, > > (-:hris > > Christian Kaiser > > SiemensVDO Automotive AG > SV SC RS T33 > Osterhofener Straße 19 - O19 > 93055 Regensburg > Germany > > Tel: ++49 (0)941-790-6689 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Headings
Hi Scott, It sounds like you may be putting the background on the block containing the text. Try putting it on the table-cell itself or even on the row. HTH, Karen Scott Moore wrote: > > I'm creating tables for FOP that have a black background with white text in > the table header. The rest of the table (the data) is inverse, with black > characters and white background. > > If the header text in a column doesn't fit on one line, it will wrap, which > is a good thing. The problem is the rest of the headers that don't wrap, > their black backgrounds stay on one line. Therefore, the whole table header > looks uneven and ugly. Here's an example, the # are the black background: > > - > -#Column#1##|#This#is#column| > - |2##| > - > - Table data| blah blah blah| > - > > Are there any settings that can automatically fix this? I've tried using > "padding-bottom='1em'" for the first column, and that kinda works, but it's > still slightly off. The problem is I won't always know which column > headings wrap because the fonts are user configurable. > > Thanks for any help! > Scott > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop speed improvements
Hi Pablo, I ran your xml and xsl files on my machine (800MHz, 256Mb RAM, Linux, JDK 1.3) and it ran in a 7 seconds using the fop command line from 0.20.2, which includes loading all the Java classes. It does look like you could generate more efficient FO, because your XSL currently makes one table for each line, each containing just one row. You could probably use 1 table with many rows instead. Also you are generating a couple of tables which have no table-column elements at all, which fop doesn't understand and skips. Try testing and refining your stylesheet using the command line interface. You can also just use an XSLT engine to generate an FO file directly so that you can see exactly what you are sending to FOP. However that isn't enough to explain the extreme slowness you see. There must be some other place in your servlet which is taking time. Good luck, Karen Lease Pablo Iaria wrote: > > The arquitecture I have is: > > 1) I call a stored procedure that answers a cursor. > 2) Traversing that cursor I build the xml file. > 3) I transform the xml file with a xsl to get a .fo > 4) Finally I use fo to get the PDF file. > > The most time consuming task is the transfomation performed in step 4 & 5. > > Thanks, > pablo.- > > PS: I'm sorry for my English, is not my natural language... > > - Original Message - > From: "Amit" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 11, 2001 3:03 PM > Subject: Re: Fop speed improvements > > > > > There are disclaimers stating that Fop is not ready for production level > use. > > However many of us use it. > > I can generate 2+ page pdfs with graphics in less than 30 seconds...this > is just > > to give you an idea. I a using JDK1.2.2 with 512MB of RAM > > If you could paste/attach your servlet code or the xml, xsl files someone > might > > be able to take a look at it to see if something is going on there. > > > > > > Pablo Iaria wrote: > > > > > Hi all, > > > This is the second message I post about fop performance and I didn't > got > > > any answer; is there a way > > > to make it faster or "useable". > > > I'm generating a pdf from a servlet and although it's very easy to > use, > > > it's VERY slow and causes the browser to raise a timeout exception. I'm > > > using a Pentium III 500 + 500 Mb + jdk1.3 machine and it takes 5 minutes > to > > > get a 2 pages document with no graphics, just one big table with 5 > > > columns... > > > > > > Am I doing something wrong or fop is not ready for "real-life" ? > > > > > > Thanks in advance, > > > Pablo.- > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > >Name: report_19261.xml >report_19261.xmlType: text/xml >Encoding: quoted-printable > > Name: reporttable.xsl >reporttable.xslType: text/xml > Encoding: quoted-printable > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ERRORS IN FOP
Hi Siarom, The problem is that your xsl file is generating a lot of formatting object structures and properties which are legal in the XSL specification, but which are not yet handled correctly by FOP. Many of these are in the "extended" conformance category, meaning they are the "nice" things to have but not part of the core product. Fop is still quite incomplete software. It can do a lot of useful work, but you have to try to live with its inadequacies. Most of the error messages you are getting indicate what FOP can't handle, but I'll give some more explanations. Fop documentation should have a list of what is and isn't supported, but it may well be incomplete or out of date--it changes as the developers add new things. margin property: this is XSL shorthand for top-margin, bottom-margin, left-margin, and right-margin. For FOP you will have to specify them individually. font property: this is another shorthand which Fop doesn't understand. Instead of font="bold 14pt Helvetica", you'll have to use separate attributes, like this : font-family="Helvetica" font-weight="bold" font-size="14pt" reference-orientation and text-transform are not yet supported as the message says Ignore all the error messages like this about border-xxx-style: [ERROR]: Unknown enumerated value for property 'border-top-style': medium are actually false. In fact, Fop shouldn't print this, and it correctly interprets the border shorthand. But it only knows how to do border-style="solid". border and padding aren't supported on region-body. This is actually stated in the XSL specification Tables: this is why your xsl crashes completely. FOP needs table-rows to hold the table-cell objects. It doesn't yet know how to use the starts-row and ends-row properties on table-cell to simulate rows. It also needs to have a table-column object for each column, and a "width" attribute on the table with a fixed width. (I will soon commit some changes which implement proportional column widths, but you will still need the table-column and table-row objects). So in short, you will have to modify your XSL to make things more explicit for FOP. However, you should be able to get about the same result. Good luck, Karen Lease Siarom Egrub wrote: > > Hi All, > > Thanks for your input. I enclosed a copy of error.txt along with the XML and XSL >files. These are just test files, as I am trying to get acquainted with FOP. Like I >wrote in my earlier email to the group, I'm just getting started on FOP. I am not >sure if these problems are cause due to environment settings. > > Sorry for been a pain!! > > Thanks for your help, > > S. Egrub > > Find the best deals on the web at AltaVista Shopping! > http://www.shopping.altavista.com > > > Name: error.txt >error.txtType: Plain Text (text/plain) > Encoding: 7bit > >Name: test.xsl >test.xslType: unspecified type (application/octet-stream) >Encoding: base64 > >Name: test.xml >test.xmlType: unspecified type (application/octet-stream) >Encoding: base64 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop Error
Hi Siarom, It looks like it could be something in property interpretation (divide by zero!). Please run fop using the -d switch to get a complete stack trace of the error. Then copy that as text from your DOS window and paste it into your message (it will be a lot smaller than sending the screen shot in a Word document). (Or perhaps putting "> error.txt" after your command line will put the output into a file which you can send.) You probably also want to attach your xsl and xml files if they are a reasonable size. Regards, Karen Lease Siarom Egrub wrote: > > Hi All, > > Please assist me in comprehending the error in the following attachment. I am very >new at FOP! Any help will do! > > Thanks in advance, > > S. Egrub > > Find the best deals on the web at AltaVista Shopping! > http://www.shopping.altavista.com > > > Name: fop-error.doc >fop-error.docType: Microsoft Word Document (application/msword) > Encoding: base64 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using FOP in Servlet
Joerg,
I think the easiest way to do this is something like this (taken from
the Fop task in org/apache/fop/tools/anttasks/Fop.java)
Configuration.put("baseDir", SOMEURLSTRING);
You may want to do the whole configuration initialization process anyway
just to get things like compression and fonts. When running FOP from the
command line, most of the configuration work happens in the Options
class (org.apache.fop.apps), so you might want to look at that too.
Regards,
Karen Lease
Joerg Pietschmann wrote:
>
> Hello,
> i use FOP in a servlet together with the Saxon XSL processor.
> I implemented the communication between the processors as
> a SAX event stream. The following code snippet was developed
> with FOP 0.20.1, i think with 0.20.2 i could use the Driver
> again but i don't want to bother with this yet.
>
[SNIP...]
> The problem i want help about is the exception
> [ERROR]: Could not set base URL for svg
> java.net.MalformedURLException: no protocol:
> at java.net.URL.(URL.java:473)
> at java.net.URL.(URL.java:376)
> at java.net.URL.(URL.java:330)
> at org.apache.fop.svg.SVGElement.layout(SVGElement.java:143)
> at
>org.apache.fop.fo.flow.InstreamForeignObject.layout(InstreamForeignObject.java:198)
> at org.apache.fop.fo.flow.Block.layout(Block.java:259)
> Fortunately, the file renders fine, the missing information is
> aparently not needed.
> The SVG is defined in the XSL file. How do i set the base URL for
> the SVG element, just in order to pacifiy the software? Should i use
> a real file name (for example the name of the XSL file) or is it
> sufficient to use ""?
>
> J.Pietschmann
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: table questions (column wiidths)
Louis, Unfortunately, you can only use absolute values for the column-width attribute currently (like 3cm). I'm currently planning on adding support for the proportional-column-width() function in table-column which would provide a similar way of specifying widths. For example, to get three columns of equal width, you would use: The table-width must be specified and the layout set to "fixed" in order for this to work. But the table-width itself could be a percentage, which is interpreted relative to the block containing the table. I'll certainly post to the list when I get this done. Regards, Karen Lease [EMAIL PROTECTED] wrote: > > Folks: > > 1) Can I use a percentage for the column width? For example: > > > > 2) Is the 'auto' table layout implemented yet? > > 3) Is it possible to dynamically declare my table columns using a > for-each? For example: > > > > > > Thanks in advance. > > -Lou > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Newbie question: Error: Null
Paul, It looks like the "ParserFactory" is looking for (and not finding) the Sun parser rather than the xerces parser which comes with the Fop package. This could be due to having an old version of the jaxp.jar or parsers.jar (or maybe crimson.jar) on your classpath. Is the CLASSPATH variable set? Do you have any of these jars in your lib/ext directory under your jdk or jre installation diretory? Or do you have a file called jaxp.properties under your jre/lib directory which would specify a value for the property called "javax.parser.SaxParserFactory"? Hope that helps, Karen Paul Kowlessar wrote: > > Amit, > > I did as you asked and here is the resulting exceptions. I'm stumped. > > /**/ > > javax.xml.transform.TransformerConfigurationException: > javax.xml.parsers.FactoryConfigurationError: com.sun.xml.p > at > >org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:815) > > at > org.apache.fop.tools.xslt.TraxTransform.getTransformer(TraxTransform.java:50) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:100) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:80) > > at java.lang.reflect.Method.invoke(Native Method) > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:76) > > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:49) > > at PDFTest.(PDFTest.java:87) > at PDFTest.main(PDFTest.java:107) > - > javax.xml.transform.TransformerException: > javax.xml.parsers.FactoryConfigurationError: > com.sun.xml.parser.SAXPars > at > >org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:813) > > at > org.apache.fop.tools.xslt.TraxTransform.getTransformer(TraxTransform.java:50) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:100) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:80) > > at java.lang.reflect.Method.invoke(Native Method) > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:76) > > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:49) > > at PDFTest.(PDFTest.java:87) > at PDFTest.main(PDFTest.java:107) > - > org.xml.sax.SAXException: javax.xml.parsers.FactoryConfigurationError: > com.sun.xml.parser.SAXParserFactoryImpl > at > >org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:771) > > at > org.apache.fop.tools.xslt.TraxTransform.getTransformer(TraxTransform.java:50) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:100) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:80) > > at java.lang.reflect.Method.invoke(Native Method) > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:76) > > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:49) > > at PDFTest.(PDFTest.java:87) > at PDFTest.main(PDFTest.java:107) > - > org.xml.sax.SAXException: javax.xml.parsers.FactoryConfigurationError: > com.sun.xml.parser.SAXParserFactoryImpl > at > >org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:771) > > at > org.apache.fop.tools.xslt.TraxTransform.getTransformer(TraxTransform.java:50) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:100) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:80) > > at java.lang.reflect.Method.invoke(Native Method) > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:76) > > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:49) > > at PDFTest.(PDFTest.java:87) > at PDFTest.main(PDFTest.java:107) > java.lang.reflect.InvocationTargetException: > java.lang.NullPointerException > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:102) > > at > org.apache.fop.tools.xslt.TraxTransform.transform(TraxTransform.java:80) > > at java.lang.reflect.Method.invoke(Native Method) > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:76) > > at > org.apache.fop.tools.xslt.XSLTransform.transform(XSLTransform.java:49) > > at PDFTest.(PDFTest.java:87) > at PDFTest.main(PDFTest.java:107) > [ERROR]: Logger not set > [INFO]: building formatting object tree > [SNIP SNIP] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP-0.20.2 Release Candidates posted
I haven't downloaded the release candidate (slow network at home), but I've noticed a small problem in my latest CVS which I assume is the same. When using runtest.sh in docs/examples with the new targets which use a "" instead of listing all of the individual ".fo" files, I'm getting this error on extensive.fo which uses SVG, even though it's embedded. Could not set base URL for svg java.net.MalformedURLException: null: java.lang.NullPointerException Also, the fo test files using external images are failing with a null protocol. The problem is in the ant Fop task which isn't setting the basedir correctly in the case of the fileset. I have a patch for that, but I'm still getting errors with the relative URLs for the external images, which are being mis-interpreted by my JDK. I can't figure out if this is a JDK bug (Sun 1.2.2 on x86 Linux), or whether the code in the FopImageFactory is at fault. The URL "file:../../graphics/blah.gif is made into the absolute URL: "file:/graphics/blah.gif" ! Sound familiar? I know lots of people have been complaining about similar problems; maybe this is related? Regards, Karen Arved Sandstrom wrote: > > Hi, all > > I built and uploaded the tarballs for the binary and source distributions, > for FOP-0.20.2. They are labelled as release candidates. Please test and let > me know what needs to be fixed. Thanks. > > I am shooting for a final build on Tuesday. > > The CHANGES file is not yet updated - I will be working on that. > > Regards, > Arved Sandstrom > > -- > Fairly Senior Software Type > e-plicity (http://www.e-plicity.com) > Halifax, Nova Scotia > Wireless * B2B * J2EE * XML > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Page Breaks
Hi Amit, Use the attribute 'break-before="page"' on an FO (like fo:block or fo:table). In general, for basic "how-to-use" XSL-FO questions you might want to look at some resources other than the list. The W3C proposed recommendation isn't light reading, but there are some introductory articles and explanations to be found at various places on the Web which can help you learn how to use XSL-FO. You can start at: http://xml.apache.org/fop/resources.html Good luck, Karen Amit wrote: > > Is there a way to insert a bage break in the pdf that I am trying to > generate using > a xsl fo tag in my xsl file? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: space-before in fo:table-row
According to the XSL-PR, space-before isn't applicable to table-rows, table-cells and table-body objects. Try using padding on your cells and perhaps no borders depending on the effect you want. HTH, Karen [EMAIL PROTECTED] wrote: > > I want to use spacing in tables to do normal management reports. > I use something like > Is this implemented yet? I can't seem to get it to work. > Does anyone know when it might be available? > Does anyone know an easy way to get a blank row in a table to emulate the > above? > Trev > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
Keiron Liddle wrote: > > Hi All, > > I have been doing some performance testing so we can get an idea of how > things might be improving (or getting worse) with changes to the code. [snip] > So the question is: can we drop java 1.1 support and use better data > structures? Interesting results! With java 1.4 just around the corner, I think we can and should "byte" the bullet and stop trying to keep FOP compilable with Java 1.1. I know there are a few loyal Fop users out there whose corporate structures are still several versions behind. It's too bad for them, but FOP _is not_ legacy software and should be able to move quickly. It's also hard for us to keep the code compatible since I suppose almost all of us are developing on at least Java 1.2. So +1 for me. Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Another servlet problem
You could try using getOutputStream and then building your own Writer by putting on an encoding. The IllegalState is because you can't use the Writer and the OutputStream in the same servlet. But it seems to me if you've already written something to the output and the FOP output is appended on to that, it won't be a legal PDF file... -Karen Carmelo Montanez wrote: > > Hi All: > > Thanks for the help yesterday. I am doing a similar thing as AMIT, > however my servlet > gets the writer before it gets to the PDF stuff (I need it for other > reasons) and > I get the Exception: > > "java.lang.IllegalStateException: getWriter() has already been called for > this response" > > Any way around that? > Carmelo > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP support for number-rows-spanned property
David, I don't think it was in 0.19.0, which is consistent with the error message. The reason for the infinite loop may well be that some group of rows which are held together by spans is too big to fit on the page. This is a known bug, and I'm not currently working on it, as it's not that easy to do. Like many difficult layout issues, we hope to attack this in the "redesign". However, just to make sure that there isn't some other wierd reason for this problem, I'd be happy to look at your .fo file. Regards, Karen "David S. Dixon" wrote: > > Karen, > > Was number-rows-spanned support in 0.19.0? I have an .fo file that turns into a > .pdf file under 0.19.0 but complains of > > WARNING: Number of cell columns under table-row not equal to number of > table-columns > > for the two rows corresponding to the spanned rows. Under 0.20.1, fop goes into > an infinite loop on this file. > > -dd > > Karen Lease wrote: > > > Hi Amit, > > > > The number-rows-spanned property is now implemented in FOP, but it > > wasn't yet in 0.18.1. If you want to use it, you should download the > > latest version of FOP from the website - that's 0.20.1. > > > > Regards, > > Karen > > > > [EMAIL PROTECTED] wrote: > > > > > > I'm not sure if this is the right place to ask such a question... if not, I > > > would appreciate some information on where to find a solution to this > > > problem :- > > > > > > I've been trying to use the "number-rows-spanned" property to generate > > > tables in my PDF file using FOP 0.18.1. However, I keep getting errors - is > > > the "number-rows-spanned" property not implemented in FOP yet? > > > > > > Thanks for your help > > > amit > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[REDESIGN] Layout Manager ideas
Hi all, I've been turning over some ideas about LayoutManagers, FOs and Areas and what's responsible for what. I've concentrated for now on the layout of inline stuff, for two reasons: a) we know the current area tree is incorrect at this level b) if we don't make Lines, the Block LayoutManager has nothing to work with. The scenario runs like this: A Block FO makes a Block Layout Manager (BLM). We probably want to have a factory mechanism for making Layout Managers, since that way we can use more or less elaborate ones. The Block FO then iterates over its children. It makes one Line LayoutManager for each sequence of inline-area producing children. (So an FO has to be able to tell what kind of areas it produces.) The Line LayoutManager (LLM) has as children the layout managers returned by each of the FO children of the Block FO. The most interesting kind of InlineLM is the TextLM which should have the word-breaking logic in it. There are TextLM implementations for different script systems, like typical Western and CJK. Once the hierarchy of LM is setup, the layout process starts. A BLM gets told (or asks for?) its inline-progression dimension (IPD). It then makes a BlockArea and gets areas from its child LM to fill the block areas. layoutManager.getArea(LengthRange inlineProgDim, LengthRange blockProgDim, LayoutInfo info) The layoutManager should return an area which fits in the inlineProgDim (minimum, optimum, maximum). For the LineLayoutManager, it will make a LineArea. It will then asks its child LM for areas which it will add to the LineArea. It manages the stacking in the inline direction, including space-specifier calculation. The LM for Inline FOs which contain other inline FOs basically acts the same as the LineAreaManager, but they make InlineAreas and not LineAreas and then propagate the getArea() to their kids. The TextFO is responsible for breaking at word breaks and/or legal hyphenation points. (Hyphenation logic should probably be a kind of plug-in to this and not be directly in the TextLM. One think I'm considering is the possibility of hyphenating runs of text which are actually part of two different TextFOs, possibly even at different tree levels.) The LayoutInfo is used to propagate information about layout state-- things like whether the current LM can make any more areas (whether all the content in its FO has yet been laid out), whether an inline area ends on a hyphen, whether an inline area ends on a breakpoint (space or other potential line-break character), etc). The created areas know their sizes, described as a rectangle relative to their baseline point for alignment purposes. Containing areas calculate their sizes based on what child areas they contain. In short, most of the work that is currently done by the FOs is now done by the LayoutManagers. However, I think it's more than just moving code around. The LayoutManager class hierarchy can be different from the FO hierarchy. In particular, LM for objects which only manage other LM can be the same or very similar. Most of the work for inline layout should be in the TextLM. Obviously I'm eluding the floats for the moment, but this needs to be integrated quickly. The LM interface also has to know how to split existing areas and not just to make new ones. Suivant? (Next?) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP support for number-rows-spanned property
Hi Amit, The number-rows-spanned property is now implemented in FOP, but it wasn't yet in 0.18.1. If you want to use it, you should download the latest version of FOP from the website - that's 0.20.1. Regards, Karen [EMAIL PROTECTED] wrote: > > I'm not sure if this is the right place to ask such a question... if not, I > would appreciate some information on where to find a solution to this > problem :- > > I've been trying to use the "number-rows-spanned" property to generate > tables in my PDF file using FOP 0.18.1. However, I keep getting errors - is > the "number-rows-spanned" property not implemented in FOP yet? > > Thanks for your help > amit > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ETA on 0.20.2
Hi Keiron, I'll fix the bug 3531 (column-number attribute not working on table-column) before the release unless you're already working on it. Also willing to give a hand with updating the website. Regards, Karen PS. I'm working away on LayoutManager ideas and hope to contribute something before or on the coming weekend. Keiron Liddle wrote: > > We should probably have a 0.21 release sometime in the next two weeks. > > Things that will need doing are: > - testing for any unnoticed problems > - building and putting the release on the server > - update the website to reflect the new version > - changes list, todo list, status etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug list
Hi Corinna and welcome back, Your idea sounds quite good to me. Speaking as a committer, I'm sure I could spare a few minutes every now and then to commit the bugtest files. Actually I've got rather a bunch of files lying about already with names like "bug1234.fo" :-) Since you've been absent for a while, you may not be aware that Keiron has added a new test directory which works on the principal of using the "XML renderer" to compare the results of running two versions of FOP on test files. You can find some information and examples in the xml-fop/test directory and in the documentation (Testing). Perhaps the bug files should be integrated there. Cheers, Karen Corinna Hischke wrote: > > Hi all, > > I've been digging around the bugzilla buglist an found that there are many > bugs referring to 'very old' FOP versions like 0.17, 0.18. > > I know you can attach test files to your bug report, but wouldn't it be > easier to trace old bugs, if we integrated the test cases into the fop > tests? > > The test directory already has a 'bugtest' subdirectory. But to find a test > case referring to a specified bug, you have to do a lot of interpretation > .. > > My suggestion would be this: > - if someone reports a bug, (s)he should add a test file > - the test file would be added (by committers - sorry about that ;)) to the > bugtest directory > - the test file must be named with the bug number. > > That way anybody could easily test, wether a given bug is still current in > the used FOP version. > > What do you think? > > - Corinna > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Convert xml to pdf
Hi Steven, I hate to tell you this, but 0.14 is a REALLY OLD version of FOP and no one here is probably going to be able to help you. The best thing would be for you to update your FOP distribution (http://xml.apache.org/fop) and get the latest 0.20.1 version. The command line has changed but there should be a bat file to help you get it going. The binary download should have all the jars you need. Good luck, Karen > Steven De Schutter wrote: > > Hello > > I'm trying to convert a XML-file to a PDF-file . Now I'm working in > DOS ... but I'm getting a FATAL ERROR. > > This is what I'm doing ... > > java -cp > >c:\jdk1.2.2\lib;c:\jdk1.2.2\bin;C:\fop-0_14_0\lib\w3c.jar;C:\fop-0_14_0\fop_bin_0_14_0.jar;C:\xerces-1_4_3\xerces.jar;c:\xp\xp.jar;c:\xt\xt.jar;c:\xt\sax.jar;c:\xt\dom.jar; > -Dorg.xml.sax.parser=com.jclark.xml.sax.Driver > org.apache.fop.apps.XTCommandLine doc1.xml documentPDF.xsl doc.pdf > > When I try to execute this commando ... I get this .. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Design Tasks
I guess I'm not yet 100% where the boundaries between all this stuff is. Too bad we can't do a whiteboard session... -Karen Arved Sandstrom wrote: > > At 10:56 PM 9/10/01 +0200, you wrote: > >Hi Keiron, > > > >I'd like to think about Layout Managers, but I'd be more than happy to > >bat ideas around with anyone else who's interested in that. > > > >Karen > > Well, you already know that I am interested in that, but I backed off > because I thought you would want to take that. But I'll be happy to help. > > Regards, > Arved > > Fairly Senior Software Type > e-plicity (http://www.e-plicity.com) > Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: how to keep together
Hi Suhail, Actually to keep two different FO together, you need to use keep-with-next or keep-with-previous. The keep-together property means to keep an entire FO in the same page or column (if possible). For example, if you put keep-together on an fo:block, FOP should try to keep the whole block in the same column/page. Unfortunately, support for all kinds of keep- properties is quite limited in FOP. They work fairly well on table-rows. Keep-with-next is (I think) at least partially supported on fo:block, so try using that on the block before the table. Good luck, Karen Suhail Rashid wrote: > > Hi, > > As keep-together is not supported in > FOP as of now how can i ensure that a table > and a preceding block appear together on the > same page.. > > Please pass on any ideas u have.. > > Thanks in advance, > > Suhail > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Design Tasks
Hi Bodo, Maybe it's Windows or maybe it's your Xslt task. The fact that the parser can't find a URI for your document sounds familiar. I mad a change in Xslt a couple of weeks ago which I think might fix this. Assuming you are updating from CVS, please make sure you update the sources and then rebuild the buildtools.jar. using the command "build -buildfile buildtools.xml" in your xml-fop directory. Hope that helps you. -Karen Lease Bodo Teichmann wrote: > > Keiron, > now i got the pdf but still have the following problems: > 1. the relative uri in fop.xml do not work. i get the following error from > the SAX parser: > >Task xslt - SAX ERROR: > > org.xml.sax.SAXParseException: Relative URI "design/intro.xml"; kann > nicht > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Design Tasks
Hi Keiron, I'd like to think about Layout Managers, but I'd be more than happy to bat ideas around with anyone else who's interested in that. Karen Keiron Liddle wrote: > > Hi All, > > These are the design tasks that I think we need to cover before (serious) > coding is done on the new layout approach. . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Layout Redesign
Hi Keiron, I have read your design document carefully several times. The layout manager idea has a familiar ring to it... something I had thought a bunch about but never formalized as you have done. In essence, it sounds like it would handle a bunch of stuff that the FO classes themselves are currently trying to do. I was hesitating about moving more logic into the areas themselves, but I think your idea of having a "middle man(ager)" is better. One attractive idea is that we could start with a fairly basic manager as you describe, but could perhaps develop more sophisticated ones in the long term (ie, manager is strategy). Also it's clear that the manager which is doing line breaking (the Inline Manager?) will exist in different versions to handle different kinds of writing-modes and styles (western, CJK...) I was trying to find a time when I was feeling more coherent to put my questions and remarks together, but given all the traveling I'm doing for work that's not happening. So I'll just start here by writing down a few things that came to mind. Then if I've misunderstood what you meant, we'll find out sooner. I think my main concern is to be sure I understand where you are actually thinking of doing the line building, ie. where the inline-progression-dimension (IPD for short) of the columns will actually be determined. Obviously this depends on the selection of the page master to be used to hold the areas. That's a big part of what motivated my bottom-up approach. If the block layout managers (BLM) are actually created before the page is made, then they can't make lines yet. That is one of the ideas I had been playing with. In that case the manager is managing one or more "inline flow sets" which is what I had called a sequence of characters and other inline content which wasn't yet broken into lines. The BLM might also manage nested BLM. When the parent manager asks the BLM to produce an area, it sets the IPD and so the inline flow set can be broken into lines. In general, all the layout managers need to know the IPD in order to work. For examples non-fixed table layout depends on it, leaders, and other expandable content like images which are scaled to available space. For me this is a key issue. Also you talk about how floating objects would be removed from the page while looking for the best break, but you don't talk much about how they get put on. Are you thinking they will be added at the moment where the anchor is encountered? They at least have to be queued at that point or signaled to the page-level LM. You mention that the BLM manages the anchors. I was thinking of delegating to the LineArea objects themselves; but obviously the key idea is that something knows about them since the areas attached to them can move around during page breaking. Just a language issue: you talk of page balancing which makes me think of balancing a multi-column page above a span or at the end of a flow; but you seem to be using it to mean optimizing the break and distributing the resulting vertical space. The term "VJ" for "vertical justification" is often used for that process. I like the user-agent idea a lot; it seems like an elegant way to handle a lot of configuration issues. I remember worrying about that sometime last year when I started to look at property values like "thin", "thick", "smaller", etc. I'm looking forward to continuing the discussion here. Regards, Karen Keiron Liddle wrote: > > Hi All, > > I have written a document describing a possible way that we could implement > the layout process (also has some info about user agent). > > I am hoping for feedback (particularly from those who have looked at the > layout - Arved, Karen, Peter and others). > > It is mostly a description so there still may be some gotchas that I > haven't considered. Hopefully this can provide some impetus to moving > forward with the layout design so we can handle all these requests for > things like keeps, spacing, line breaking (chinese characters), floats, > large images, infinite loops etc. For those new to this area handlng a lot > of these things is difficult with the current layout process in fop, hence > the need for a new approach. > ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Xslt task issue (was Re: [GUMP] Build Failure - Fop)
Hi fellow foppers, Concerning the recent GUMP build failures, Sam Ruby wrote: > ... the following change: > >http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23&r2=1.24 > > ..causes the following build failure: > >http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html Our stylesheets (like genconst.xsl) which use the XSLT document function with an input nodeset are failing. The problem is that Xalan isn't finding the base URL for the node in the XML document. In fact it doesn't have a URL for the input XML document at all! I now see that the reason for this is that the Xslt task used in the fop build is building a DOM Document from the input file and passing that to the transformer. If I modify org.apache.fop.tools.anttasks.Xslt to directly pass the input XML filename to the XSLTransform.transform method, the latest version of Xalan works correctly, since it now finds the base URL. We are building the DOM tree to handle the "mergefile" which is used when building the font files. In order to work with the new version of Xalan, we need to find some way to let it know the system ID of the original input document. Perhaps we could create a DOMSource directly? Or pass the system ID separately? Or find some other way to handle the font mapping files without building the DOM tree? I haven't thought much about the best way to do this; I'll probably mull it over a bit, but it would be nice to hear from those of you who have already mucked about with this stuff (Tore, Kelly, Fotis?). Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Borders not lining up
Hi Steve, There are at least 2 reasons I can see for your confusion about the dimensions. 1. The border.fo file defines an A4 page, which is slightly longer than a US. Letter size page. Acrobat may be scaling the whole image to fit on Letter size paper which can account for the table being smaller than normal. I have verified the numbers in the PDF file and printed it on A4 paper and the table dimensions are correct. If I let Acrobat think it's printing on Letter, the dimensions are in fact too small. 2. The way dimensions are calculated in the block-container FO is a bit different than in fo:table. In the block-container, the top and left properties position the "content rectangle" and the padding and border are positioned OUTSIDE of that rectangle. So the actual drawn border will be wider than the "width" value. In the rectangles under "Sales Receipt" for example, there is padding of .6mm on each side of the rectangle, which is added to the width. The border is outside of that. In the fo:table, the column widths define the table-grid. In the border-collapse=separate style being used, the cell borders are drawn INSIDE the table-grid. So the border to border measure is less than 2.5cm. Also, in absolutely positioned block-container objects, top and left are meassured with respect to the content-rectangle of the page-region. In this case, that is offset .5cm from the actual paper edge. Concerning the problem about the text "creeping to the left" in the table columns, I can't reproduce this behavior with the border.fo file. Or perhaps I don't understand what you mean? Hope that helps a bit, Karen Lease Steve McCardle wrote: > > Hi, > > Firstly, ... am I in the right place for queries of this nature ? (I've > tried fop-dev-help & fop-dev-info already !) > > I'm completely new to FOP and just getting to grips with the examples > provided, so I'm probably going to sound really dumb. > > I've been running through the samples provided in the FOP directories and > I've noticed that, in the example "border.fo", there seem to be a few > anomalies: > * the measurements do not seem to add up either horizontally or > vertically; > * in the section which defines the address/Sold To/Ship To etc., once > I've established where I think the "zero" edge is, the "left" or "top" edges > of the block definitions just don't seem to measure up ! > * in the table definitions, the 4 column widths add up to 19cm but > physically they only print about 17.9cm ! > * the text in some of the columns (of the table) seem to "creep" over > to the left even though "end" alignment is specified; > I've used the white-space-collapse="false" option to see if that makes any > difference - but that doesn't help; > It seems to be affected by the length of the text in an earlier column > (Description); padding the shorter descriptions with spaces "seems" to help > a bit, but not totally; and using the monospace font doesn't seem to have > made any difference either. > > So, am I doing something incredibly stupid or this a "feature" that I have > to work around ? > > Thanks, > > Steve McCardle > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
Struan, Oops, I hadn't noticed the second version of addLine taking the ruleStyle since it wasn't being called in the doFrame stuff when I made my change. Duhh. The baseline alignment stuff is harder than the straight "after" align. Our line-height calculations need to be right before we get into that, so it's probably not coming up right away. Cheers, Karen Struan Judd wrote: > > Karen, > > I figured that might be the reason. > > And yup, at the moment somthing is better than nothing. > > Also, Nope. No change to the addLine code was needed. > I'm currently running the 0.20.1 release with only my patch to PrintRenderer > as that's what we'll be deploying here so I haven't seen the current CVS but > maybe there's been a change since then. > > and lastly, I haven't checked the vertical alignment issue as with what I'm > doing display-align="after" does not achieve the align to the last baseline > for different sized font's across table cells, (Whew!) that I needed. > > Thanks anyway. > > TTFN > > Struan Judd <*> "And so it begins ..." ICQ: 4498196 > http://neongraal.sf.org.nz > mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) 305-1011 x1006 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Hi fop and xalan dev, The problem here seems to be that the XSLT document function, when called with a single argument which is a node-set (in the fop case, a single element or attribute node) is now using the current directory as the base URI to resolve relative URI references. It should use the base URI of the node, which would seem to be the base URI of the XML document containing the node. The documents FOP is trying to process are in the same directory as the original XML documnent being processed. I think the FOP XSL is correct, but of course, I could be wrong... Regards, Karen Lease Fairly Fanatic Fopper Sam Ruby wrote: > > FYI - The following change: > > >http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23&r2=1.24 > > ..causes the following build failure: > >http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html > > - Sam Ruby > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: please help!!!
Hi Eric, Sorry if no one has answered your plea before now. Unfortunately (or perhaps fortunately?) I don't have any problem with the example you sent. I'm using the latest CVS, but if you are using an earlier version of FOP, you probably should try with the latest release which is 0.20.1. I've attached the PDF I generated, using a simple A4 size page master. I assume this is the result you want? It's true that the overflow property isn't implemented yet in FOP, but Yyou shouldn't need to use it here, since the text is just wrapping normally in the table cell. Overflow is really meant for flow objects which won't fit at all on the page and should be clipped. An example would be a large graphic. "eric.deandrea" wrote: > > I have a table with 4 columns. One of the cells has text in it that is > bigger than the size of the column and the text is over-writing the text in > the following cell. How do I stop this? I have this: > > > > > > > > > > text-align="start" > font-size="10pt" > line-height="14pt" > overflow="hidden" > wrap-option="wrap"> > This is some text in cell 1 that > will over-write the text in cell 2. > > > > text-align="start" > font-size="10pt" > line-height="14pt" > overflow="hidden" > wrap-option="wrap"> > This is some text in cell 2. > > > > text-align="start" > font-size="10pt" > line-height="14pt" > overflow="hidden" > wrap-option="wrap"> > This is some text in cell 3. > > > > text-align="start" > font-size="10pt" > line-height="14pt" > overflow="hidden" > wrap-option="wrap"> > This is some text in cell 4. > > > > > > > -Eric > > > Eric Deandrea > Software Engineer (978) 698-6351 > Inforonics, Inc. [EMAIL PROTECTED] > 30 Porter Rd. > Littleton, MA 01460 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] ericbug.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
Hello Struan, It looks as though you must have changed addLine as well to add the border-style, since that isn't in the current version (at least not the one I got from CVS last night.) I'm the one responsible for changing this code in doFrame because when borders are drawn using "lines" in PDF, it didn't seem possible to avoid pixel errors in the segment joins. This made for ugly table borders. It's also true that the dashed border style is the only one which could be (at least partially) handled using the PDF line operator. Due to the fact that we the doFrame code draws four separate lines instead of stroking a single path, I imagine that the the dashes are not going to work great in all cases anyway. However I understand that you may feel something is better than nothing. Could you submit your modified addLine code as well? We will try to come to some satisfactory solution. (Sorry if you'd already done this; I've been away for a few days and might have missed an earlier message in the stack I went through last night.) Regards, Karen Lease P.S. Also, I believe the 0.20.1 version of FOP should fix the problem you reported in late July concerning vertical alignment in table-header rows when the table was continued. If not, please let me (fop-dev) know! Struan Judd wrote: > > Instead it uses the fillRect routines. > > Unfortunately, I needed to have a dashed border (in PDF's) and so put back > (well not exactly hence the query) the old ways. Which seems to work fine > (for me). > > If the reason for the change was that some of the other renderers couldn't > cope, perhaps their addLine routines could be changed to redirect to the > fillRect ones. > > In any case, could the other line styles please be restored to FOP-PDF. > > Here is the diff of org.apache.fop.render.PrintRenderer of what I've done > (between the ''s): > > > 364c364,365 > < addFilledRect(rx, ry, w, top, > --- > > addLine(rx, ry, rx + w, ry, top, > > bp.getBorderStyle(BorderAndPadding.TOP), > 365a367,369 > > // addFilledRect(rx, ry, w, top, > > // new > PDFColor(bp.getBorderColor(BorderAndPadding.TOP))); > > > 367c371,372 > < addFilledRect(rx - left, ry - h - bottom, left, h + top + > bottom, > --- > > addLine(rx, ry - h, rx, ry, left, > > bp.getBorderStyle(BorderAndPadding.LEFT), > 368a374,376 > > // addFilledRect(rx - left, ry - h - bottom, left, h + top + > bottom, > > // new > PDFColor(bp.getBorderColor(BorderAndPadding.LEFT))); > > > 370c378,379 > < addFilledRect(rx + w, ry - h - bottom, right, h + top + > bottom, > --- > > addLine(rx + w, ry - h, rx + w, ry, right, > > bp.getBorderStyle(BorderAndPadding.RIGHT), > 371a381,383 > > // addFilledRect(rx + w, ry - h - bottom, right, h + top + > bottom, > > // new > PDFColor(bp.getBorderColor(BorderAndPadding.RIGHT))); > > > 373c385,386 > < addFilledRect(rx, ry - h - bottom, w, bottom, > --- > > addLine(rx, ry - h, rx + w, ry - h, bottom, > > bp.getBorderStyle(BorderAndPadding.BOTTOM), > 374a388,389 > > // addFilledRect(rx, ry - h - bottom, w, bottom, > > // new > PDFColor(bp.getBorderColor(BorderAndPadding.BOTTOM))); > > > TTFN > > Struan Judd <*> "And so it begins ..." ICQ: 4498196 > http://neongraal.sf.org.nz > mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) 305-1011 x1006 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
Ralph, Yes, actually that was clear. I should have said, there isn't a _layout_ problem with borders, but I agree, there was/is a rendering one. -Karen Ralph LaChance wrote: > > At 06:53 PM 8/7/01 +0200, you wrote: > >Koen (and Ralph and others), > > > >There is a problem, but it's not a border-drawing problem. > > Karen, > > Sorry, I wasn't clear -- I'm suggesting there are ~two~ separate problems > here. The first is what you describe below. The second is: given > the fo such as it is, it renders differently for -print and -awt versus > -pdf. On both -awt and -print no border is drawn for the table cells. > The pdf renderer ~does~ draw the table borders. > > The awt/print problem is due to AWTRenderer attmpting to fill a rectangle > with either the width or height of zero. This happens when the border size > drops below a threshold (i.e., 500 millipts) This all stems from a patch > to AWTRender I supplied a few weeks ago in which, among other things, we > made AWTRenderer honor actual border sizes. > > (The original 0.19.0 AWTRenderer drew ~all~ borders 1 pixel thick, > regardless of border-size.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Table Status (was Re: problems with height of cells in tables)
Hi Arved (and other interested parties), Lots of other bugs (like the inline-area height) show up well in tables because the grid makes things visible. That's the case with the trailing white-space bug I saw the other day, resulting in an empty table row. Some of these can also be shown by using border, padding and background on fo:block, which also needs more test cases. I think base-level table functionality has gotten considerably better, and we need to publicize that with the next release, since there have been so many problems in the past releases. Of course, I know there are still a number of bugs, but I think the row-spanning, vertical alignment and general border-handling improvements should help lots of people. Off the top of my head, here are major areas for work: 1. border-collapse=collapse. There is a partial bandaid for this now. I've written a lot of pseudo-code for this, as the general case is quite complex. It should take into account cell, row and column borders (though I'd like to see the final word in the PR on this). As often, I ran up against the problem of handling the break conditions, since that can affect the borders. But unless someone else has done lots of work here or has some easy improvements, I'd like to keep it on my plate (after vacation). 2. Keeps and breaks. There are some cases where breaks cause problems; as I recall the culprit is in table-body. I know the general problem of keeps can't really be handled, but tables are a particularly sore point for that. It's worth trying to do keep-together for table-row; actually I think I did a first pass on this when I did spans. 3. Handling limit conditions, like table-row with keeps but which doesn't fit on the page. 4. Indents. Just looked at Koen's bug, which involves the indents not affecting the table itself, but rather the cell content. My reading of the CR is that the areas created by fo:table are block areas and should be positioned by indents. Lots of people also want to center their tables; I can't figure out how this is supposed to happen, unless it's in table-and-capation. 5. The table-and-caption fo. 6. Row-less tables using start-row and end-row properties on the cells. I think this can be handled in addChild for the table-body by creating "fake" TableRow objects as needed. 7. Automatic table layout style (this is a fairly big deal). Or at least really implement the percentage stuff, which would be simpler and still quite flexible. This needs some work in calculating the column widths once the size of the containing reference area is known. 8. The relative-align style for vertical alignment. Needs post-processing once all cells in the row are done. Might as well wait until we get our line-stacking straightened out. That should keep people thinking for a while... There are also a few remarks below. I'll be away from my Internet access for a while, so this is probably it for now. Overall the idea seems good. Obviously if I've temporarily let go of bottom-up layout, it was to try to reduce the volume of table-related complaints. Regards and "a bientot" Karen Arved Sandstrom wrote: > > Hi, Karen (and other interested parties) > > A thought occurred to me just now. A high percentage of our bandwidth (and > bug reports) are devoted to tables. There are so many table-related bug > reports mainly because so many folks want to use tables, I believe, not > because there are more bugs in tables than elsewhere. > > I'm thinking that perhaps we can use table support as the centrepiece for > all of our FOP efforts. In order to have tables be fully supported, and work > properly, a really big percentage of the XSL specification (and FOP > mechanics) gets exercised. Redesign of layout is something of a fuzzy goal; > making tables work isn't. > > You've currently got probably the best perspective on tables. What I am > thinking would be useful would be a report concerning table FOs, with a > property-by-property breakdown, that assesses what works, and what doesn't, > and what needs to happen in order to make things work. This could drive a > whole bunch of tasks that people could take on. It would be easier to gauge > the progress of FOP, because table support would be a bellwether for FOP as > a whole. > > This doesn't mean that everything else would be ignored. But the shift of > emphasis would be as follows: if I want to work on markers, I make sure that > they work inside fo:table-and-caption, fo:table, fo:table-caption, > fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If > someone wants to make sure FO X works, they make sure it works also as a > descendant of fo:table-cell. Keiron has laid the groundwork for testing - a > really suitable area for a first comprehensive set of test-cases could be > (you guessed it) tables! :-) KL: Agreed. I started to do some test cases, but then discovered I needed to add more properties to the AreaTree concerning borders and padding. I didn't get arou
Re: Nesting tables in FOP
Hi Vicki, I believe there is a small problem in your XSL stylesheet. You've written: I think you mean ''. That will cause the content of tableA to be processed to create the nested table. By the way, you probably could simplify your stylesheet quite a bit. If you just say , it will process all the children of the current node in order. Also in your elements, you only need to match on the entire context of an element if you need to do something different depending on where the element appears. For example, you might be able to use: in the rule above, since your structure seems quite unambiguous. Hope that helps you on your way, -Karen Lease [EMAIL PROTECTED] wrote: > > I am using FOP 0-19-0.CVS and having problems nesting tables. Just as > a simple test I am trying to place one table inside a block, within a > single outer table cell. The PDF output does display the values, but > entirely ignores the inner table structure by placing the values on a > single row. > > I have seen some of the other discussions on this issue, eg, setting > column widths, yet have not been able to resolve the problem. Attached > is the xsl fragment. > > Does anyone know how to overcome this, or have an example of code that > will give me something to work from? > > Many thanks > Vicki > > > Name: Test_fo_5.xsl >Test_fo_5.xslType: unspecified type (application/octet-stream) > Encoding: base64 > > > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
Koen (and Ralph and others), There is a problem, but it's not a border-drawing problem. You have a left-margin specified as 2cm on a block which is containing the paragraphs before the table and the table itself. This property is inherited and is therefore used on both the fo:table and the fo:blocks inside the fo:table-cell objects. What isn't normal is that the table itself should be indented by 2cm and it isn't. But that in itself won't fix the cell text alignment, since the margin (or start-indent which is the same thing) is being inherited by all the content inside the table. So the cell content would still be badly positioned. Assuming that FOP handled indent correctly on the table, you would want to set it back to a smaller value, on table-body for example. In the meantime, there is an ugly workaround involving an empty first column whose width is equal to the current indent and which only has borders on the right side. As Arved has just suggested focusing on tables, this problem will be a good place to start and I'll try to put it on the high priority list. Regards, Karen [EMAIL PROTECTED] wrote: > > Hello, > Hello Karen, > > I tried it with the snapshot of the night before yesterday (due to the > firewall I cannot get into CVS directly). It was not rendered > correctly. > > I have included the document (doc.xml) and the stylesheet > (doc2pdf.xsl) that lead to docxalan.fo > > If rendered to awt few borders are rendered and those rendered are not > aligned with the table. > If rendered to pdf all borders ara rendered but all are not aligned > with the table. > > The version I'm using is from a file called > xml-fop_20010806101537.tar.gz (it is stating FOP 0.19.0-CVS at > startup) > > Kind regards, > > Koen. > > Please respond to [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
