Re: Drop RTF Support?
... I'm sorry. That didn't make sense. Could you please repeat it, using something more closely resembling actual English? I don't actually understand your point or even what your sentences are trying to say. As to the point on CSS, nobody wants to use a broken CSS renderer. They simply have to, and nobody likes that circumstance. Nobody's asking Microsoft to make Internet Explorer non-CSS compliant. b.ohnsorg wrote: Nicol Bolas wrote: In any case, RTF lacks the full degree of expressiveness possible from XSL-FO anyway, so some information is going to get lost. What's the point of doing the XSL-FO transform to begin with if you didn't want your stuff to have a particular look to it? It's like wanting to use a broken CSS renderer for your HTML; you may as well not have bothered with the CSS to begin with. Did you ever argue with a sort of «big spender» about paying your ideas AND knowing, that he'll have to pay 100times more to get his workers on XSLT-level? Some people even don't care 'bout rockets flying through an empty space, reaching a «big rock» and sending back some stones, so why can't there be people who don't care 'bout what XSLT even means and have absolutely no idea of «document editing» beyond type-mark-make bold+underline? (And your CSS-argument is quite dangerous, some browser, only a few, very little *g* don't support CSS. Can you imagine, that it's not possible to have auto-content in something called Internet Explorer *g*? But you could use ActiveX to render nearly anything with curves, lines and realtime-3D, which would be even closer to reality...) -- View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12083281 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
Ultimately, I guess, it depends on what you're using FOP for.
I see XSL-FO as a means to print files. Or store them in a printable format.
XSL-FO is not an interchange format; it is not PDF, nor should it be looked
at as such. It exists to be converted into something based on the semantics
defined in the XSL-FO specification.
For all their promises of WYSIWYG, neither Word nor OpenOffice (nor the
formats they read) are WYSIWYG. Their formats cannot exactly conform to the
XSL-FO specification. They can come close, but they're not the same.
What a person wanting to put documents in a Word-readable format wants is to
be able to take his original XML file and turn it into something that can be
used by someone else. In that case, what is necessary is an XSLT to convert
the XML into ODF or whatever.
In any case, RTF lacks the full degree of expressiveness possible from
XSL-FO anyway, so some information is going to get lost. What's the point of
doing the XSL-FO transform to begin with if you didn't want your stuff to
have a particular look to it? It's like wanting to use a broken CSS renderer
for your HTML; you may as well not have bothered with the CSS to begin with.
Plus, there's the fact that ODF attempts to retain some basic semantic
information, which has already been lost by the time the XSL-FO comes
around. Since this information cannot be recovered, the ODF file produced
from an XSL-FO would be, at best, visually functional. But ideas on what
constitutes a title or whatever are completely lost. One would get much more
functional ODF files by writing a custom XSLT for the format. Plus, the
format isn't exactly that difficult to use.
Mark C. Allman wrote:
I only meant that if we replace the RTF capability with something
equivalent. I use the RTF generation so that I can then convert a few
things to MS Word (can't ignore the 800 pound gorilla in the room). I
think ODF was in the post I replied to, so I just used that as an
example.
What I do now is the following:
doc.xml --|
doc.pdf
|-- XSLT ENGINE -- doc.fo -- FOP -- {
doc.rtf }
translator_doc.xsl
--| .
Putting something into FOP to generate ODF wouldn't make much sense,
IMHO. I think it'd just be another xslt script to translate the FO file
to ODF. Or write a plug-in for OpenOffice to read in FO files
(obviously another project!).
I think we'll lose users if we don't keep something that lets them
generate docs that are interoperable with the 800 pound gorilla. How we
do that is the question.
Just my 2 cents
-- Mark C. Allman,
PMP
-- Allman
Professional
Consulting, Inc.
-- 617-947-4263
--
www.allmanpc.com
BusinessMsg -- the
secure, managed,
J2EE/AJAX
Enterprise IM/IC
solution.
On Wed, 2007-08-01 at 11:29 +0200, Vincent Hennebert wrote:
Hi Mark,
Mark C. Allman a écrit :
Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
Swap out RTF with, say, ODF? Sounds great to me.
I'd even volunteer some time to help with development. I seem to
remember something about Java ;-]
Thanks for your offer to help!
However... would that make sense to produce ODF from XSL-FO? There is no
semantic construction at all in FO, whereas there is some in ODF. The
other way around looks much more useful to me; as style informations are
stored using FO, this should be very easy to convert an ODF document
into plain XSL-FO.
Typically the transformation chain:
XML — XSL-FO —+— RTF
|
+— PDF
would be replaced by:
XML —+— XSL-FO — PDF
|
+— ODF
WDYT?
Vincent
--
View this message in context:
http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12062102
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
You missed several important points, however. First, ODF and OOXML are not WYSIWYG formats. They cannot do what XSL-FO says that they should. So any transformation from XSL-FO to ODF or OOXML is fundamentally wrong. It violates the XSL-FO specification in various ways, and there's no way to know what the output will actually be. XSL-FO processors don't exist to generate something. They must generate a specific thing (within tolerances, of course). They must do exactly what they are told, as defined by the XSL-FO specification. And if an output format can't handle what the spec says to do, then it is the output format that is wrong. The second problem is that ODF and OOXML have semantic constructs that XSL-FO cannot replicate. Dates, chapters, etc, all of that information has been lost by the time the FO was generated. So the ODF or OOXML files generated from a FO will be, not wrong, but entirely unsemantic. Your DocBook document with its nice chapters and so forth will end up with just text. Formatted text, as per the FO, but the concept of chapters, articles, etc, have all been lost, and ODF/OOXML have the semantic structures to contain some of these. So, from the perspective of making a proper XSL-FO implementation, ODF/OOXML formats are bad. And from the perspective of making a good ODF/OOXML file, using FO as a source is bad. The best you could hope to get out of this code path is something that looks OK. And what's the point of bothering to generate complex XSL-FO documents if all that descriptive power goes to waste? I mean, XSL-FO has all of this expressive power, and the most you can think to do with it is throw it away on an ODF file? Mark C. Allman wrote: Well...not exactly, IMHO. What a person wanting to put documents in a Word-readable format wants is to be able to take his original XML file and turn it into something that can be used by someone else. In that case, what is necessary is an XSLT to convert the XML into ODF or whatever. By analogy, if I want to put XML data in PDF format, do I write XSLT to convert it to PDF? We don't do that now. We write an XSLT script to covert to XSL-FO, then the FOP engine converts to PDF. The FOP engine is a converter from XSL-FO to something else. Word, ODF, RTF, PDF, text, whatever. We all already write XSLT scripts to transform from data (XML) to XSL-FO. I'm not trying to be argumentative at all, just also not demanding of a project team that's providing me a great tool at no cost to me. I'd like to keep RTF, or in it's absence have something I can use in its place. Also, people who ask for things should be prepared to chip in and help. BTW, also IMHO, it'd be cleaner to have one XSLT super-script to convert from XSL-FO to ODF (or OOXML or whatever Microsoft calls their open standard). If I write an XSLT script to transform data in XML to an ODF document then I write it for each schema. So if I want to generate both PDF and ODF then I'm forced to write two XSLT scripts (one to XSL-FO and another to ODF). If we wrote an admittedly rather complex XSLT script to transform from XSL-FO to ODF then we'd only write it once. It's an academic point, since I think writing such an XSLT script is outside the bounds of the FOP project. No scope creep here, please. Just my 2 cents -- Mark C. Allman, PMP -- Allman Professional Consulting, Inc. -- 617-947-4263 -- www.allmanpc.com -- View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12065161 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: [2007/02/11] fop.bat needs patching
I do not believe that most Windows machines came with a JavaScript interpreter. As such, expecting a user to have to install one in order to use FOP is an unnecessarily high bar. However, if the 'cmd' language and the 'bat' languages are fairly identical, feel free to change them. As long as the user doesn't have to install a program just to use FOP, I don't see a problem. Simon Pepping @ Home wrote: On Wed, Mar 07, 2007 at 04:32:09PM -0800, Nicol Bolas wrote: Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? In the past three months we have had two incidents where the startup script fop.bat lagged behind the update of a jar file. One such incident forced me to cancel 100MB of candidate release files, fix that batch file and create and upload 100MB of new candidate release files. You would not gain anything as long as we suffer the pain of maintaining the startup script in the age-old, powerless batch language designed for x86 computers in 1990. We would gain the comfort of a more powerful language, which is able to find out itself if a jar file has changed version number. In addition, the javascript file offers customizability to the users. Until someone creates a comfortable GUI for FOP, you better learn what cmd and js files are. Or at least, you learn that you can execute them by double clicking on them, just as the batch file. B.T.W. the cmd and bat file languages are the same language on recent Windows systems. It is just that the batch file does not use more powerful features of that language, in order to enable you to run the same on a Windows 98 computer. My Windows 98 system broke down quite a while ago, but there seem to be people who are kinder to it, and have kept it alive until now. Simon, who prefers to spend his time and efforts on forward looking features -- Simon Pepping home page: http://www.leverkruid.eu -- View this message in context: http://www.nabble.com/fop.bat-needs-patching-tf3361048.html#a9387403 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: [2007/02/11] fop.bat needs patching
Andreas L Delmelle wrote: On Mar 7, 2007, at 22:49, Simon Pepping wrote: On Wed, Mar 07, 2007 at 03:58:18PM +0100, Jeremias Maerki wrote: Grr, I actually changed it but forgot to commit. Thanks for handling it. On 07.03.2007 10:42:38 Adrian Cumiskey wrote: This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi? id=41778). Keep it broken, so people are going to use the cmd or js startup scripts. :-) Seriously: Is it possible/feasible/desirable to change the .bat file to use one of the cmd or js startup scripts maybe? Or promote their usage in other ways? Has their usage info already been added to the docs? Cheers, Andreas Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? -- View this message in context: http://www.nabble.com/fop.bat-needs-patching-tf3361048.html#a9366292 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: XSL-FO 2.0 workshop in Heidelberg next week
Oh, I found a good one in the 1.1 spec. Remove page-position=last/only; there is no way to guarentee that it can work. There is no algorithm that can make it work in the general case. Sure, if the last page and the page that would have been there had it not been the last page used the same region content rectangle, then it's fine. But the user is not so constrained; the user can use any page. If the content is small enough that it fits on the not-last-page version, but is too big for the the last page version (or, in 1.1's case, doesn't even provide a region body that is in this flow's region map), then it can't be the actual last page, as you need another. It's fundamentally impossible in the general case. If they can't be removed, then at least provide some warning to the user about unresolvable cases. And provide some specified behavior from the FO processor in this case (chop off the content, etc). I suppose one could cheat by adding a blank last page ;) But I imagine the user would be pretty upset by that... -- View this message in context: http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6751725 Sent from the FOP - Dev mailing list archive at Nabble.com.
Generating Javadoc FOP documentation
How do you go about generating the Javadoc FOP documentation? -- View this message in context: http://www.nabble.com/Generating-Javadoc-FOP-documentation-tf2419876.html#a6746559 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: XSL-FO 2.0 workshop in Heidelberg next week
A few. I do think, when proposing these things, it is important to remember that XSL-FO is not intended to implement all possible typsetting operations, that it still needs to remain easily implementable. I guess one question I have is how different should XSL-FO 2.0 be from 1.1? Should it just be some minor changes/fixes, or are they considering some pretty substantial changes? Because if it is the latter, I've got some suggestions with that regard: * Eliminate entirely the notion of unbounded page lengths/viewports. That is, browser-like viewing with scrollbars and such. This, among other things, has the effect of making the viewport stuff unnecessary and substantially clarifies the specification and any descriptions thereof. The primary purpose of XSL-FO is for paged media; we already have tools for unpaged media. * Seriously reconsider having block-level elements and inline elements be interleaved. It probably makes FO processor implementation a bit more difficult. Plus, it's just needless; you can easily wrap that inline stuff in a block. * Page specification (simple-page-master) could be made so much more intuitive. It is far too easy to put a header in the middle of your content by accident, and while I support that functionality, it should not be the default. If it's just minor changes: * Allow for lists that periodically reverse the left/right (IPD, technically) positioning of the blocks. Generally, to allow for lists that alternate one after another which side the content and which side the list item is on. It would, also, be useful to alter other attributes when doing this. There is a FO-processor that has an extension to do it, but I forget its name. This alternation would likewise be reset at every page/region break. * In that same vein, similar alternation patters for table row properties that reset at page/region breaks. This would allow for alternate color backgrounds, but that always start (wherever they are visible) on a particular boundary. * FO 1.1 added the ability to have multiple body regions on a page, and a flow map to dictate how data flows from one to another. What was not added were appropriate keeps/breaks to deal with the possibility of switching to a new region without leaving the page itself. This distinction should be made. * The ability to specify 2-up/4-up/etc style page generation. This cannot be done even with FO 1.1's multiple body regions, because one lacks the ability to have multiple static content regions on a page, as well as where those regions get placed. Something like a multiple-page-master that physically shrinks several simple-page-masters onto a single page. * Footnote numbering/indexing per page or region, rather than leaving it up to the FO document. The numbering, of course, needs to be flexible and user-definable (perhaps as a sequence of character possibilities that is referenced). * Meta-data needs to be handled in some way. A section, perhaps just after the page master section, would be ideal. * Please give us a RELAX NG+Schematron schema for XSL-FO. It would be so incredibly useful to have such a thing. -- View this message in context: http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6727041 Sent from the FOP - Dev mailing list archive at Nabble.com.
