You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Matthias Fischer <m....@abc-media.de> on 2001/12/13 10:27:21 UTC
Basic aspects
Hallo developers,
I think I should give my contribution in backing Keiron's statement. Please
note that this is not some kind of a stuck-up, disengaged spectator's point
of view. I think the FOP developers have done a great job, sacrificing time
and money to achieve what has been achieved, and - as a beneficiary of it -
I'd like to thank you for it cordially. I also would like to express
gratefulness towards those who helped my colleagues and me in our wading
through the difficulties we met on our way.
To help you to understand better who speaks: I am not a thorough-bred
programmer. As a consultant, I'm trying to analyze different customers's
needs, and as the mentor of my own company's programmers I develop ideas and
help my colleagues in persuing these objectives.
There are no programmers in our company capable of messing with the source
code of Cocoon, or FOP, or anything linked to it. Therefore, sometimes FOP
is to us like a black box, which doesn't make things easier.
As a user, or "customer", however, I could express some clearcut opinions
which might be interesting feedback for FOP developers:
- Documentation. I know, there is no entitlement to documentation, or to
anything else, in an open-source project. Nevertheless, I found that (a) W3C
specs are great, but envisage no practical approach for those, like us, who
are not the ultimate specialists; (b) books seem to be scarce, contain
sometimes wrong or misleading information, are too superficial in their
examples, i.e. show what anyone would retrieve from somewhere in the
internet anyhow, and not always are systematic. It has cost us thousands and
thousands of Euros to get hold of simple, necessary-to-operate information.
Something like "SelfHTML", a site very popular among German HTML designers,
would be needed.
- Sometimes, I have the impression that FOP is a bit too web-oriented. I
don't know whether it's true, but both my colleagues and I, at a certain
point, got the impression that, when the HTML output side was finished,
somebody said: "And what are we going to do next?", with someone else
answering: "Let's do PDF". Of course, PDF is, first of all, a "portable"
data format, i.e. it's web-oriented. But, more and more, it is used for
typographical purposes. However, it is not possible to get anywhere near to
printshop quality unless EPS and TIFF files of a certain resolution rate can
be used. However, using twenty TIFFs of 1MB each puts FOP k.o. in a few
milliseconds. due to my own experience, FOP seems designed to be uses with
JPG/GIF pictures at 72dpi which look fine through the internet and on an
ordinary office printer. Or take hyphenation: given the number of languages
involved, certainly not an easy task. On the other hand, if hyphenation does
not work properly - and we havent't got it to work properly with the W3C
spec's language and country attributes for German and Germany - the output
scores a further little minus
(thinkofthoselongGermanwordswhich-iftheysliptothenextline-dontlooktoowell...
), and these minus points accumulate.
Please let me underline at this point that FOP is held by us a valuable and
very useful invention. We'll continue to utilize it, and we'll propagate the
use of it. Nevertheless, it would be encouraging to see the effort, which is
necessary to get it on its way, being reduced.
You might reply: "So, why don't you get involved and help making it better?"
Rightly so. The answer is: I can't, I haven't got the expertise. What I can
do, I've done - to utter my point of view with some detail.
Cordially
Matthias
-----Original Message-----
From: Keiron Liddle [mailto:keiron@aftexsw.com]
Sent: Wednesday, December 12, 2001 3:55 PM
To: fop-dev@xml.apache.org
Subject: Re: need help
[...]
While that is true there are certain things you need to realise.
- there are serious layout issues that need to be addressed
- performance and memory is very much tied up to how the whole system
works, this makes it difficult to fix
- getting FOP to a stage where there is a clear development direction is
difficult
- none of this will happen by itself
It appears that more effort needs to be put towards communicating the
issues involved and the way in which FOP can be improved.
Yes it does need to be much better.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects
Posted by Matthias Fischer <m....@abc-media.de>.
Unfortunately, no patch. As I said before, I'm not a programmer.
A tentative to start a documentation on graphic file types, yes.
I had to pass it on, as I wouldn't be in possession of all the information
to fill out _all_ the fields of a 2D matrix.
To my knowledge, nobody has picked it up, neither to complete it, nor to
insert it into the apache webpage.
Have a nice evening (CET), Keiron, I have to bring my boy to the
kindergarden Xmas party. I'll reply tomorrow (CET) to possible suggestions
by you (or others).
Matthias
-----Original Message-----
From: Keiron Liddle [mailto:keiron@aftexsw.com]
Sent: Thursday, December 13, 2001 3:46 PM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects
I presume that was a frustrated email :)
One point I have to make:
You say that you have gone through all the problems and eventually sorted
them out after working through it etc.
Yet after solving the problem you did not write to the list and say (to my
knowledge): I have worked out how to solve a particular problem with FOP,
here is a patch for the website so others will know how to solve this
problem.
If this was done then someone else won't come along, exactly like you, and
explain how frustrating things are and how someone should make things
better. If many people do a bit then there will eventually be a lot of
info.
The limitations page is probably the place for this. ie.
docs/xml-docs/fop/limitations.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects
Posted by Keiron Liddle <ke...@aftexsw.com>.
I presume that was a frustrated email :)
One point I have to make:
You say that you have gone through all the problems and eventually sorted
them out after working through it etc.
Yet after solving the problem you did not write to the list and say (to my
knowledge): I have worked out how to solve a particular problem with FOP,
here is a patch for the website so others will know how to solve this
problem.
If this was done then someone else won't come along, exactly like you, and
explain how frustrating things are and how someone should make things
better. If many people do a bit then there will eventually be a lot of
info.
The limitations page is probably the place for this. ie.
docs/xml-docs/fop/limitations.xml
On 2001.12.13 15:35 Matthias Fischer wrote:
> Not entirely correct, Arved. I'm not a great specialist on literature,
> but I
> recall reading Tortilla Flat by J. Steinbeck at school. I remember a
> woman
> in the story who faked to clean her flat with a vacuum cleaner - the
> _first_
> vacuum cleaner in Tortilla Flat - although there was no electricity in
> the
> entire quarter...
>
> The FOP documentation "problem", as I see it, is a combination of
> different
> factors. It has happened to us quite frequently that something didn't
> work,
> and we had to
> 1 find documentation on FO which supplied us with, say for instance, 2
> contradictory statements on the syntax of an attribute; neither worked
> 2 assume devoutly that we had committed an error (true in 50% of the
> cases)
> 3 find out, whether someone would understand our problem and give us a
> solution
> 4 still have problems
> 5 back to 1
> Sometimes the source of the problem was that a feature of FO wasn't
> implemented, or that it wasn't implemented with a certain FOP version;
> that
> a problem was due to performance problems; that I didn't succeed in
> articulating what I needed so that someone would understand it, or that
> answers wheren't formulated in a way that I understood them etc. etc.
> You can immagine that, for instance, non-appearing graphics lead into
> intensive testing with regard to (a) the behaviour of FOP/Cocoon under
> different Windows versions (b) different compressions of graphic files -
> nothing. Then someone in the list tells you, the region containing a
> graphic
> must be big enough, otherwise FOP tacitly drops the picture. Hormons of
> happiness spread throughout the office. The result: some files appear,
> some
> not. Why? Questions, counter-questions and counter-counter-questions to
> the
> list: because FOP does with GIF's so and so, and with TIFF's so and so
> etc.
> Ok. Learn everything you didn't know about graphic formats. Implement it.
> Wait 10 minutes, and you don't get your file compiled.
> Testing-testing-testing: no significant result.
> Question-question-question:
> because of a performance problem. How to solve it? Hmmm... - Another
> session
> of questions and counter-questions bothering other people while they try
> to
> do honest work. The hapiness-generating answer: portion the stuff you
> send
> through the processor. How? Does anybody know how to accomplish this?
> Please
> help... - Etc. etc. etc.
> I quoted the example of graphics because it was the most nerve-consuming.
> Nevertheless, by far it wasn't the only one.
>
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them. Right
> on
> the FOP page where everybody cannot avoid to take notice. With a big, red
> or
> yellow triangled exclamation mark and the wording: Hey, dummies (like
> me):
> before you get into this business, think of what you wanna achieve and
> consider these warnings, or it'll cost you real time+effort=money!
>
> Imagine a database outputting a table with all the FO commands in one
> column
> and updated, fresh-of-the-day remarks, warnings, examples etc. like above
> in
> the example. Enhanced, XML-based search functions. Sit back, take a
> drink,
> and find in a second all the bottlenecks that would have otherwise broken
> your neck.
>
> Am I a dreamer? Yes, I am.
> Can dreams come true? Yes, they can.
>
> Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Keiron Liddle <ke...@aftexsw.com>.
As you have visited the site you will know the information here:
http://xml.apache.org/fop/testing.html
This is all the information.
The plans are to get FOP to be able to run through all the tests first.
Of course if more people were involved then someone could work on
improving this.
Maybe this could be used to produce an output of information that users
could see.
On 2001.12.17 08:07 Matthias Fischer wrote:
> Great!
>
>
> What are _your_ plans with regard to the material offered by W3C/Carmelo?
>
> How are tests conducted? Is there a check list according to which one
> could
> record/submit test results systematically?
>
> Do you think, the access of the database by FOP users (and not
> necessarily
> developers) can be enhanced in order to permit easier spotting of single
> test pieces relevant to a user's specific problem?
>
> These questions are what comes to my mind after heaving visited the site.
>
> Matthias
>
>
> -----Original Message-----
> From: Carmelo Montanez [mailto:carmelo@nist.gov]
> Sent: Friday, December 14, 2001 8:43 PM
> To: fop-dev@xml.apache.org; bdelacretaz@codeconsult.ch; Matthias Fischer
> Subject: Re: Basic aspects (big fat list vs. live test documents)
>
>
> Hi all:
>
> Regarding the FO test suite. We at NIST in conjunction with the W3C
> Developed
> a test suite for FO. The site is:
>
> www.w3.org/Style/XSL/TestSuite/
>
> We are also working on expanding that work to include ALL of the basic
> aspects of the language. We expect to have close to 5000 tests by
> next march. Any contributions, ideas, etc. will be
> appreciated.
>
> Thanks
> Carmelo Montanez
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Thank you, Bertrand.
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Monday, December 17, 2001 9:49 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
[...]
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
I'd prefer a more systematic approach: let's wait until the e-mail address
exists. I fear a prefix, as you proposed, is not user-friendly enough.
Before starting, we should also devise the "smallest possible document" into
which users could then insert their functionning examples. This would make
sure that everybody builds upon the same basis. It would make the samples
more easily comparable.
Matthias
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Tuesday, December 18, 2001 10:20 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
ok, right now we don't have an alternative address available.
I suggest that you post your code to the list, inline (not as an attachment)
with [TESTDOC] in the subject line (I hope I'm not breaking an existing
convention here).
We can then find it easily in the mailing list archives.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 18 December 2001 09:59, Matthias Fischer wrote:
> Right now, I have a pice of code I would contribute. It would be useful, if
> there were an alternative e-mail address to that of the list, to collect
> the submitted code segments.
ok, right now we don't have an alternative address available.
I suggest that you post your code to the list, inline (not as an attachment)
with [TESTDOC] in the subject line (I hope I'm not breaking an existing
convention here).
We can then find it easily in the mailing list archives.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Right now, I have a pice of code I would contribute. It would be useful, if
there were an alternative e-mail address to that of the list, to collect the
submitted code segments. Users could put this docu adress on CC, and you
could filter the stuff to heap it up somewhere until it gets used.
Matthias Fischer
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Monday, December 17, 2001 9:49 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
[...]
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 17 December 2001 09:07, Matthias Fischer wrote:
> What are _your_ plans with regard to the material offered by W3C/Carmelo?
As mentioned by Keiron (see http://xml.apache.org/fop/testing.html), the
current FOP tests are based on automatically comparing the ouput
of two FOP revisions.
This is needed to make sure new releases don't break existing features, but
IMHO doesn't make it easy for end users to find out exactly how FOP
interprets specific features.
Again, I think what would help end-users a lot (and also have good tutorial
value) would be small self-describing XSL-FO documents where one can check
the results by reading the PDF, along with an "official" list of which
samples work and which don't.
Nice and well, but I don't think anyone on the FOP team currently has time to
fully set this up (but I'd be happy to be proven wrong!).
There are quite a lot of FOP samples already
(http://xml.apache.org/fop/examples.html), some more useful than others, so
maybe it's just a case of sorting through the samples, classifying them and
making them easily accessible, ideally using a live Internet-accessible FOP
setup.
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Great!
What are _your_ plans with regard to the material offered by W3C/Carmelo?
How are tests conducted? Is there a check list according to which one could
record/submit test results systematically?
Do you think, the access of the database by FOP users (and not necessarily
developers) can be enhanced in order to permit easier spotting of single
test pieces relevant to a user's specific problem?
These questions are what comes to my mind after heaving visited the site.
Matthias
-----Original Message-----
From: Carmelo Montanez [mailto:carmelo@nist.gov]
Sent: Friday, December 14, 2001 8:43 PM
To: fop-dev@xml.apache.org; bdelacretaz@codeconsult.ch; Matthias Fischer
Subject: Re: Basic aspects (big fat list vs. live test documents)
Hi all:
Regarding the FO test suite. We at NIST in conjunction with the W3C
Developed
a test suite for FO. The site is:
www.w3.org/Style/XSL/TestSuite/
We are also working on expanding that work to include ALL of the basic
aspects of the language. We expect to have close to 5000 tests by
next march. Any contributions, ideas, etc. will be
appreciated.
Thanks
Carmelo Montanez
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Carmelo Montanez <ca...@nist.gov>.
Hi all:
Regarding the FO test suite. We at NIST in conjunction with the W3C
Developed
a test suite for FO. The site is:
www.w3.org/Style/XSL/TestSuite/
We are also working on expanding that work to include ALL of the basic
aspects of the language. We expect to have close to 5000 tests by
next march. Any contributions, ideas, etc. will be
appreciated.
Thanks
Carmelo Montanez
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 14 December 2001 10:05, Matthias Fischer wrote:
> However, you won't escape "big maintenance" so easily:
Right - maintaining such a test suite is not light work.
The advantage over pure documentation, however, is that both users and
developers directly benefit from having strong test documents.
So I think it would be easier to get the FOP community to work on building
such a test suite (or organize/document existing tests) than finding someone
to write and maintain documentation.
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Not all too bad, I think - if I have understood you right.
One of the unbcertainties in most of the problematic stages of our work was
that we didn't know whether _we_ had commited an error, FOP didn't implement
some FO feature, or none of the examples we relied on was correct. A
database where to look for working examples would be of great help in these
cases.
However, you won't escape "big maintenance" so easily: Would you allow
everybody to send his/her examples uncontrolled, i.e. not really knowing
whether the stuff works or not (read: under certain circumstances works,
under others not)? Would you index the examples for easier
navigation/searching? How would outdated examples be deleted in front of
innovations of the W3C spec, or simply new programming insights by someone
contributing to the database? Santa Clause would need some helpers, he
certainly can't do it all by himself ;-)
Matthias
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Friday, December 14, 2001 8:22 AM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
On Thursday 13 December 2001 15:35, Matthias Fischer wrote:
> . . .
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them.
> . . .
I'm skeptical: to me "big fat list" means "big maintenance work" and usually
"out-of-sync list".
I'd rather have many small, focused, self-documented, numbered XSL-FO
example
files that show what works and what doesn't in FOP (note that I haven't
looked at our test files for a while - maybe it's there already?).
Maybe a live FOP system where users can post a ZIP containing XSL:FO +
graphics files and get back the PDF?
(got to tell Santa Claus about this one ;-)
Such examples could be donated by users after they find that a particular
feature works or not, with a standard mail header ([TESTDOC] ?) that would
help committers sort out these files.
Any thoughts?
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 13 December 2001 15:35, Matthias Fischer wrote:
> . . .
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them.
> . . .
I'm skeptical: to me "big fat list" means "big maintenance work" and usually
"out-of-sync list".
I'd rather have many small, focused, self-documented, numbered XSL-FO example
files that show what works and what doesn't in FOP (note that I haven't
looked at our test files for a while - maybe it's there already?).
Maybe a live FOP system where users can post a ZIP containing XSL:FO +
graphics files and get back the PDF?
(got to tell Santa Claus about this one ;-)
Such examples could be donated by users after they find that a particular
feature works or not, with a standard mail header ([TESTDOC] ?) that would
help committers sort out these files.
Any thoughts?
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects
Posted by Matthias Fischer <m....@abc-media.de>.
Not entirely correct, Arved. I'm not a great specialist on literature, but I
recall reading Tortilla Flat by J. Steinbeck at school. I remember a woman
in the story who faked to clean her flat with a vacuum cleaner - the _first_
vacuum cleaner in Tortilla Flat - although there was no electricity in the
entire quarter...
The FOP documentation "problem", as I see it, is a combination of different
factors. It has happened to us quite frequently that something didn't work,
and we had to
1 find documentation on FO which supplied us with, say for instance, 2
contradictory statements on the syntax of an attribute; neither worked
2 assume devoutly that we had committed an error (true in 50% of the cases)
3 find out, whether someone would understand our problem and give us a
solution
4 still have problems
5 back to 1
Sometimes the source of the problem was that a feature of FO wasn't
implemented, or that it wasn't implemented with a certain FOP version; that
a problem was due to performance problems; that I didn't succeed in
articulating what I needed so that someone would understand it, or that
answers wheren't formulated in a way that I understood them etc. etc.
You can immagine that, for instance, non-appearing graphics lead into
intensive testing with regard to (a) the behaviour of FOP/Cocoon under
different Windows versions (b) different compressions of graphic files -
nothing. Then someone in the list tells you, the region containing a graphic
must be big enough, otherwise FOP tacitly drops the picture. Hormons of
happiness spread throughout the office. The result: some files appear, some
not. Why? Questions, counter-questions and counter-counter-questions to the
list: because FOP does with GIF's so and so, and with TIFF's so and so etc.
Ok. Learn everything you didn't know about graphic formats. Implement it.
Wait 10 minutes, and you don't get your file compiled.
Testing-testing-testing: no significant result. Question-question-question:
because of a performance problem. How to solve it? Hmmm... - Another session
of questions and counter-questions bothering other people while they try to
do honest work. The hapiness-generating answer: portion the stuff you send
through the processor. How? Does anybody know how to accomplish this? Please
help... - Etc. etc. etc.
I quoted the example of graphics because it was the most nerve-consuming.
Nevertheless, by far it wasn't the only one.
My whish to Santa Clause this year: A big fat list containing all major
graphic formats and the FO/FOP-related aspects that concern them. Right on
the FOP page where everybody cannot avoid to take notice. With a big, red or
yellow triangled exclamation mark and the wording: Hey, dummies (like me):
before you get into this business, think of what you wanna achieve and
consider these warnings, or it'll cost you real time+effort=money!
Imagine a database outputting a table with all the FO commands in one column
and updated, fresh-of-the-day remarks, warnings, examples etc. like above in
the example. Enhanced, XML-based search functions. Sit back, take a drink,
and find in a second all the bottlenecks that would have otherwise broken
your neck.
Am I a dreamer? Yes, I am.
Can dreams come true? Yes, they can.
Matthias
-----Original Message-----
From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
Sent: Thursday, December 13, 2001 2:50 PM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects
[...]
When you say "documentation", I take it you mean operating instructions,
rather than stuff about XSL per se. Correct?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
If I can specifically address one point, it is that I am curious about why
you think FOP is web-oriented at all.
If FOP is invoked from a servlet, which seems to be a popular mechanism,
then the output is indeed being delivered to Web browsers. Unless things are
different in Cocoon 2, Cocoon itself is nothing but a high-powered servlet
that uses FOP just like this.
But FOP itself has never been Web-oriented. HTML has never been produced by
any of the renderers. Nor WML or HDML or anything else Webbish. The initial
paragraphs on the main page (http://xml.apache.org/fop/index.html) do not
mention these formats at all. Speaking for myself I have always viewed FOP
as a print publishing tool, focused on producing print-quality documents.
I would not characterize PDF as web-oriented, not in the sense you mean. It
started out as a page description language, and it is stil a page
description language. It has design features that promote electronic
delivery, and this if anything makes it "web-compatible". Now, I've used PDF
since Reader 2.0, I worked for 2 years at a shop where we were intimately
familiar with PDF and did lots of early programmatic stuff with PDF (in
Perl, mostly) before the explosion of useful tools (including any Perl PDF
modules), and the PDF we produced had to be very high-quality for print
purposes. We also used extremely large TIFF files as the basis for PDF
images in those documents. So PDF may have some limitations, but I agree
that if anyone is bottlenecked right now they are probably bottlenecked
because of FOP, not because of PDF. That is, performance limitations.
I think Keiron and Karen, among others, would agree that the object of the
rewrite that they are spearheading is to allow other developers to more
usefully contribute. This should go a long ways to letting more people get
at the code.
When you say "documentation", I take it you mean operating instructions,
rather than stuff about XSL per se. Correct?
Regards,
Arved Sandstrom
----- Original Message -----
From: "Matthias Fischer" <m....@abc-media.de>
To: <fo...@xml.apache.org>
Sent: Thursday, December 13, 2001 5:27 AM
Subject: Basic aspects
> Hallo developers,
>
> I think I should give my contribution in backing Keiron's statement.
Please
> note that this is not some kind of a stuck-up, disengaged spectator's
point
> of view. I think the FOP developers have done a great job, sacrificing
time
> and money to achieve what has been achieved, and - as a beneficiary of
it -
> I'd like to thank you for it cordially. I also would like to express
> gratefulness towards those who helped my colleagues and me in our wading
> through the difficulties we met on our way.
>
> To help you to understand better who speaks: I am not a thorough-bred
> programmer. As a consultant, I'm trying to analyze different customers's
> needs, and as the mentor of my own company's programmers I develop ideas
and
> help my colleagues in persuing these objectives.
>
> There are no programmers in our company capable of messing with the source
> code of Cocoon, or FOP, or anything linked to it. Therefore, sometimes FOP
> is to us like a black box, which doesn't make things easier.
>
> As a user, or "customer", however, I could express some clearcut opinions
> which might be interesting feedback for FOP developers:
>
> - Documentation. I know, there is no entitlement to documentation, or to
> anything else, in an open-source project. Nevertheless, I found that (a)
W3C
> specs are great, but envisage no practical approach for those, like us,
who
> are not the ultimate specialists; (b) books seem to be scarce, contain
> sometimes wrong or misleading information, are too superficial in their
> examples, i.e. show what anyone would retrieve from somewhere in the
> internet anyhow, and not always are systematic. It has cost us thousands
and
> thousands of Euros to get hold of simple, necessary-to-operate
information.
> Something like "SelfHTML", a site very popular among German HTML
designers,
> would be needed.
> - Sometimes, I have the impression that FOP is a bit too web-oriented. I
> don't know whether it's true, but both my colleagues and I, at a certain
> point, got the impression that, when the HTML output side was finished,
> somebody said: "And what are we going to do next?", with someone else
> answering: "Let's do PDF". Of course, PDF is, first of all, a "portable"
> data format, i.e. it's web-oriented. But, more and more, it is used for
> typographical purposes. However, it is not possible to get anywhere near
to
> printshop quality unless EPS and TIFF files of a certain resolution rate
can
> be used. However, using twenty TIFFs of 1MB each puts FOP k.o. in a few
> milliseconds. due to my own experience, FOP seems designed to be uses with
> JPG/GIF pictures at 72dpi which look fine through the internet and on an
> ordinary office printer. Or take hyphenation: given the number of
languages
> involved, certainly not an easy task. On the other hand, if hyphenation
does
> not work properly - and we havent't got it to work properly with the W3C
> spec's language and country attributes for German and Germany - the output
> scores a further little minus
>
(thinkofthoselongGermanwordswhich-iftheysliptothenextline-dontlooktoowell...
> ), and these minus points accumulate.
>
> Please let me underline at this point that FOP is held by us a valuable
and
> very useful invention. We'll continue to utilize it, and we'll propagate
the
> use of it. Nevertheless, it would be encouraging to see the effort, which
is
> necessary to get it on its way, being reduced.
> You might reply: "So, why don't you get involved and help making it
better?"
> Rightly so. The answer is: I can't, I haven't got the expertise. What I
can
> do, I've done - to utter my point of view with some detail.
>
> Cordially
>
> Matthias
>
>
> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: Wednesday, December 12, 2001 3:55 PM
> To: fop-dev@xml.apache.org
> Subject: Re: need help
>
>
> [...]
>
> While that is true there are certain things you need to realise.
> - there are serious layout issues that need to be addressed
> - performance and memory is very much tied up to how the whole system
> works, this makes it difficult to fix
> - getting FOP to a stage where there is a clear development direction is
> difficult
> - none of this will happen by itself
>
> It appears that more effort needs to be put towards communicating the
> issues involved and the way in which FOP can be improved.
>
> Yes it does need to be much better.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org