DO NOT REPLY [Bug 6437] - Tables without fo:table-column don't render
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=6437. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=6437 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 09:20 --- This is an importand bug because a lot people want generate pdf from html or xhtml files. If you have a lot html or xhtml files and want to convert them for example with css2fop.jar you get problems with every table. because people normaly don't define a table with colgroup/col tags -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [VOTE] Move all hyphenation patterns to offo.sourceforge.net
On 17.03.2005 11:00:15 Andreas L. Delmelle wrote: -Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] -Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] ... The work to be done is: adapt the page hyphenation.html to the new situation, I'll have a closer look at FOP's hyphenation page later tonight. Proposal, IIC, is to remove the distinction between 'Standard' and 'Custom' hyphenation support, leading to a structure: - Hyphenation Support - Introduction: small adjustment to the paragraph, offering a link to OFFO here - Licensing Issues: not sure, but I'd keep this just as a reminder... Good thinking. Users should be reminded that they have to be careful, although it's less a problem for them than for the ASF. - Sources: no change required - Installing: should basically come down to a) making sure the JAR containing the hyphenation patterns is accessible to FOP, I read: make sure hyphenation patterns in an additional JAR is detected by FOP. Right? or b) making the XML available via the userconfig. You mean the uncompiled hyphenation XMLs? Not sure here. The principles will remain the same for the OOo patterns. In any case, the option of having the patterns picked up when rebuilding FOP is no longer the general use case (only if the distribution jar is out of sync with the checked out version of FOP, and even then... see below: build targets) - Hyphenation Patterns A few modifications required + when support is available, add some details about the specifics of the OOo patterns... As for the build targets: so we don't remove these, but it seems we definitely could/should tweak these to accomodate the creation of the JAR that will be offered through OFFO, via a command like 'ant hyphenation-jar', so that eventually, end-users can use this build target to compile their own hyphenation-only JARs containing only the patterns they need and want to use... Sounds better, agreed? Yes. I'll see what I can get done before the weekend (see yesterday's mail from infrastructure@), else the commits will have to wait until next week. Sounds good to me. Thanks for taking the ball! And BTW, it's good to have you active again!!! Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases indent2.xml
On 17.03.2005 15:02:02 Andreas L. Delmelle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] snip/ fo:block text-indent=20pt text-align=justify This is just for testing purpose and this line will be indented. fo:blockThis is the nested block./fo:block The text following the nested block should be indented as well. Errmm... Correction: The OP for the recent issue on fop-user claimed the exact opposite ...the text following the second block should not be indented since text-indent applies only to the first line of that block and not to any subsequent text in that block He did add, however, that he wasn't sure if this was as per spec. I'm not sure either, to be honest. You could argue that after a nested block you have a new block even if it's the same XML element creating these two blocks. Either way, it's good to have a test case around that reminds us about this issue. The checks still need to be written after all... Jeremias Maerki
DO NOT REPLY [Bug 34058] New: - text-indent is applied to all FOText areas instead of just the first one.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34058 Summary: text-indent is applied to all FOText areas instead of just the first one. Product: Fop Version: 0.20.5 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The spec for text-indent says: This property specifies the indentation of the first line of text in a block. More precisely, it specifies the indentation of the first box that flows into the block's first line box. The box is indented with respect to the left (or right, for right-to-left layout) edge of the line box. User agents should render this indentation as blank space. But the 0.20.5 version of the renderer is applying text-indent to all FOText areas within that block instead of just the first one. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34058] - text-indent is applied to all FOText areas instead of just the first one.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34058 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 16:11 --- Created an attachment (id=14507) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14507action=view) apply text-indent only if isFirst() is true. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34058] - text-indent is applied to all FOText areas instead of just the first one.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34058 --- Additional Comments From [EMAIL PROTECTED] 2005-03-17 16:13 --- Created an attachment (id=14508) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14508action=view) When looping through the childern, set isFirst() to true only for the first child -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
RE: FOP requirements and wishes
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 17 March 2005 15:11 To: fop-dev@xmlgraphics.apache.org Subject: Re: FOP requirements and wishes That's a joke, right (and I'm not referring to your name)? You don't really expect that you can demand things like that from an open source project without throwing in some resources yourself, do you? I wasn't quiet sure whether it was a joke or not ... It's audacious if it isn't! On 17.03.2005 15:55:23 Bill Gates wrote: Hello! I have a couple of comments to the FOP product. The background is that, in our next coming product we have an extreme tight schedule, and we need a powerful XSL-FO converter that fulfills the following requirements: - Small memory footprint - Efficient usage of the CPU - Conforms to XSLFO 1.0 standard - Fast We have been evaluating different kind of XSL:FO processors, both commercial and non-commercials. The best one so far is the RenderX product (concerning XSLFO 1.0 compatibility), but we think it is too expensive and takes too much resources. What we would like from you is a new release, that in conjunction to the FOP release 0.20.5 (which by the way is poor), fulfills the requirements mentioned above. I have been following the mailing-list a while, and I have the feeling that the speed regarding updates are not as fast as we would like to. I hope that you as a FOP developer, after reading this mail, really put some additional blood, sweat and tears into FOP and help us realizing our project within the timeframe we currently have. best regards Bill ps. When can I expect the stable 1.0 release to be available, I suggest at the end of july this year (latest) ds. Jeremias Maerki This footnote confirms this e-mail message has been swept by BlackSpider for the presence of computer viruses. This message and any attachment is confidential and may be privileged or otherwise protected from disclosure and is intended solely for the addressees and other authorised to receive it. If you are not the intended recipient please telephone or e-mail the sender and delete this message and any attachment from your system. If you are not the intended recipient any disclosure, copying, distribution or action taken in reliance on the contents of this e-mail or any attachments is prohibited. Any view or opinions presented are solely those of the author and do not necessarily represent those of YOUR MOVE. YOUR MOVE is a trading name of: your-move.co.uk Limited which is authorised and regulated by the Financial Services Authority (FRN:310467) for mortgage and non investment insurance advice. These details may be verified with the FSA at www.fsa.gov.uk/register Registered Office address: Newcastle House, Albany Court, Newcastle Business Park, Newcastle Upon Tyne, NE4 7YB. Registered Number: 01864469. VAT number: GB105437300. You may also contact YOUR MOVE at [EMAIL PROTECTED] This footnote also confirms this e-mail message has been swept by BlackSpider for the presence of computer viruses.
Re: cvs commit: xml-fop/test/layoutengine/testcases indent2.xml
On Thu, Mar 17, 2005 at 04:05:12PM +0100, Jeremias Maerki wrote: On 17.03.2005 15:02:02 Andreas L. Delmelle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] snip/ fo:block text-indent=20pt text-align=justify This is just for testing purpose and this line will be indented. fo:blockThis is the nested block./fo:block The text following the nested block should be indented as well. Errmm... Correction: The OP for the recent issue on fop-user claimed the exact opposite ...the text following the second block should not be indented since text-indent applies only to the first line of that block and not to any subsequent text in that block He did add, however, that he wasn't sure if this was as per spec. I'm not sure either, to be honest. You could argue that after a nested block you have a new block even if it's the same XML element creating these two blocks. Either way, it's good to have a test case around that reminds us about this issue. The checks still need to be written after all... I agree with the submitter of bug 34058. Later parts of a block should not be indented. A clear use case is this: block: The following formula nested block: displayed formula block continued: proves our point. In this example, even the sentence continues, and should not be indented. The same is true if the second part would start with a new sentence. If a user wants to start a new paragraph, with new indentation, a new block should be specified. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [VOTE] Move all hyphenation patterns to offo.sourceforge.net
On Thu, Mar 17, 2005 at 04:02:00PM +0100, Jeremias Maerki wrote: On 17.03.2005 15:02:02 Andreas L. Delmelle wrote: or b) making the XML available via the userconfig. You mean the uncompiled hyphenation XMLs? Not sure here. Yes, I wasn't sure of it myself... Ultimately, a hyph-only JAR containing only compiled patterns would render this approach obsolete --suboptimal at the very least. In that case, the userconfig page might need a small update too; the hyphenation-dir setting can be dropped. I don't think it would render it obsolete. Automatic compilation of the hyphenation patterns could be seen as user-friendly. Fewer things to do. Just a thought. It's secondary anyway. FOP is able to compile FOP-format hyphenation patterns at run time, and use the result during that run. No compiled file is written. The HEAD code does currently not listen to any user configuration to find those files. hyphenation-dir is observed in fop-0.20. In principle it would be nice to restore this behaviour, and to extend it to OOo-format patterns. But it is certainly secondary. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/src/java/org/apache/fop/area/inline InlineParent.java
On Thu, Mar 17, 2005 at 08:48:03AM +0100, Finn Bock wrote: [EMAIL PROTECTED] wrote: gmazza 2005/03/16 15:18:43 Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java StaticContentLayoutManager.java AbstractLayoutManager.java PageSequenceLayoutManager.java BlockLayoutManager.java LeafNodeLayoutManager.java LayoutManager.java BlockContainerLayoutManager.java InlineStackingLayoutManager.java BlockStackingLayoutManager.java FlowLayoutManager.java ContentLayoutManager.java TextLayoutManager.java LeaderLayoutManager.java src/java/org/apache/fop/layoutmgr/table Cell.java Caption.java Body.java TableLayoutManager.java Row.java TableAndCaptionLayoutManager.java src/java/org/apache/fop/area LineArea.java Area.java src/java/org/apache/fop/layoutmgr/list ListItemLayoutManager.java Item.java ListBlockLayoutManager.java src/java/org/apache/fop/area/inline InlineParent.java Log: Changed from addChild(Area) to clearer addChildArea(Area). Yes, that looks like a good example of the kind of change which Jeremias kindly asked you not to do right at this moment. I second that. Glen, other team members than you expect that Jeremias is about to make important improvements to these LMs, and agree with Jeremias that your working on the same piece of code is going to bother his work. Renaming, moving things around and refactoring is the worst thing you can do at such a time. Code repositories are a powerful tool, but they do not take away the problems that arise when two people are working on the same piece of code. Please, leave this area to Jeremias for the weeks to come. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Plan: Branch for page breaking
No, multi-column layout is not adressed, yet. The code is still very basic. But I think with the list of Knuth elements available this will be relatively simple to achieve. On 18.03.2005 02:21:21 Glen Mazza wrote: BTW, Jeremias, does the new code take into account column-balancing for a span-reference-area? We don't have that in our current branch.[1, line 504] Thanks, Glen [1] http://tinyurl.com/6y4np --- Glen Mazza [EMAIL PROTECTED] wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Once everything is checked in, I invite everyone to have a look at the new parts and help improve them. Great! That's a very nice offer. I hope to be able to help out some on the new branch and will cease my LM work now on HEAD. (Thanks Simon and Chris for your comments on the matter.) Glen Jeremias Maerki
