You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Giulio Buccini <gi...@libero.it> on 2007/12/27 17:37:27 UTC
How navigate/scroll inside the PreviewPanel
Hi,
I'm developing a java stand-alone application structured on the screen as
follows:
1) a tree data structure on the left side of the screen (a JTree
essentially);
2) a pdf view of tree data on the right side of the screen.
My target is to provide a clear view of the final pdf document to the user.
FOP code is re-generated after any data modification (add, remove, edit and
so on) operated on the tree.
I'm migrating my application from an HTML view to a PDF view cause of
terrible troubles rising up when HTML is printed on a A4-size paper.
As I understand, the only component that I can use to embed a PDF view in my
application is the PreviewPanel. Nevertheless, this component is very
limited: user can only jump across pages.
What I need is a trick or a workaround to implement following behaviour:
"When user click on a element in the tree the preview panel automatically
jumps to the right page and scroll to right place."
Somebody knows a workaround to make this possible?
In my old html-version of my application I have solved this problem by
inserting many hidden anchor elements in the HTML code and using the
"scrollToLink" method of the JDesktop pane component. Now I'm in troubles
cause I cannot apply the same solution with the generated pdf document...
Suggestions? Ideas?
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Giulio Buccini <gi...@libero.it>.
Hi Andreas,
I have read your reply with great interest, I subscribe all you wrote.
Nevertheless, there is a little point: I don't want to integrate a
wordprocessor-like application (like Microsoft Word); I was only stressing
on one point, the WYSIWYG methapore.
Today, customers are more smart and pretends more from software application.
As I understand, today you cannot show an application in the MS-DOS style to
your customer. Customer wants more and pretends more.
The point is that many office-automation application are today using the
WYSIWYG metaphore deeply, and Microsoft Word (that I hate) is one of the
first to brings this concept on the desktop of milions of user.
Ok? I don't want a PDF word processor at all.
My requirements is more simple: bring this concept as valid for XSL-FO (or
pdf) documents too.
Understand me, Java swings is great, but it help you until you stay inside
the confortable view of your own application; but, when you try to export
graphic contents outside of the application-box you start to become hungry:
what you get is always different from what you see on the screen.
Obviously I'm not speaking about simple graphic contents (one image, one
diagram, one little text paragraph). I'm speaking about long, hierchical,
complex documents.
This kind of documents needs a more sophisticated management: they needs to
be organized, styled, refined to allows the user to understand if that big
amount of information will be well-understood when exported (for example to
the boss of a department).
Of course, you can do all the work by yourself, arranging contents with
swing components or even with the Graphics2D object. Nevertheless, the
effort is enormous: margin, pagination, borders, fonts... wao!
The question is: why I must do all these work when there are tools that are
specialized on this kind of work? The drawback is that that tools (FOP) are
not easy to integrate in your desktop application. And that's all.
FOP is a great transcoder: from XSL-FO to PDF (not only). My point of view
is different: great libraries like FOP are reduced in usability if there is
no another tool for easy integration close to them. I'm stressing the
desktop-application integration point: in this case - and from my point of
view - this aspect increases the FOP usability in a tremendous way.
As you told, PDF format has become "ipso facto" a standard for exchanging
documents. The quality of that docs is impressive. It will be fantastic if
programmers can "show" this quality on the screen of their users. Believe
me: many times (maybe all times) long documents (with a lot of data) was not
understood by the audience cause of lack in presentation.
It will be great if java programmers can bring the powerful of pdf data
presentation to their customer.
Allows me a last point: when you wrote about an hypotethical XSL-FO editor
you still are thinking from a tecnical point of view. You think to an editor
like something for "real" programmers, the pepole appasionated in writing
any detail, even every single byte of code.
In my point of view, a real useful XSL-FO editor is something completely
different from your idea: is graphical tool that allows the user to set the
general structure of documents (colums, borders, flow of text across pages,
and so on) and after this.... generate the parameterized xsl-fo code by
himself!
A real XSL-FO editor mast save user to be bored from all XSL-FO
stuff/details (I think) .
It's fantasy? I believe not... computer must be used to simplify our life,
not to add complication...
regards, Giulio Buccini.
Andreas L Delmelle wrote:
>
> On Jan 10, 2008, at 20:00, Giulio Buccini wrote:
>
> Hi Giulio
>
>> I know: I wrote about MY requirements from MY point view... probably
>> everyone have a different view about that and is pretty impossible
>> to make
>> everybody happy. I understand this...
>
> Of course, but it is always interesting to see those different views
> posted here.
> Who knows, maybe other users have similar thoughts/needs, but have so
> far refrained from speaking up (since they already knew, more or
> less, what the answer would be).
>
>> <snip />
>> Microsoft Word is massively used inside big organizations, and the
>> base
>> concept is WYSIWG. So, if you develop a desktop application for an
>> employe
>> you will receive the -unsolited- question: why what I see on the
>> screen is
>> not what I see when I print document or when I send it by email? Why
>> application cannot show me the final result "in real time" when I
>> work on
>> data? Word is doing that! (I cannot describe my face in similar
>> situations... when I was working for SIEMENS this was one of the most
>> frequent questions...)
>
> Sure, and OpenOffice has a word-processor too, and it's also
> completely free of any charge.
> The big difference with XSL formatters, is that they are not word-
> processors, but should rather be compared to web-browsers. A WYSIWYG
> XSL-FO application would be much more like an HTML editor, and AFAIK,
> in most HTML editors, you don't really edit the page on-the-fly. You
> alter the source code, and the document is re-rendered using as much
> cached information as possible.
>
> Another huge blocker is that the transformation is far from always
> easily reversible. Creating /the/ XSL-FO source for a given PDF
> document is impossible, unless the PDF would contain a reference to
> it. For a given printed layout, there are always at least a handful
> of ways to describe/define it in FO. An XSL-FO document is more
> comparable to Tex than to Word's .doc.
>
> Looking at PDF in particular, PDF editors are also not word-
> processors. You cannot create a blank document, or alter an existing
> one, in the same sense as you would with Word. iText, for example,
> mentions in the manual somewhere that you cannot really replace text
> in the PDF using the iText API, but you would have to create a new
> text box containing the replacement and place that over what needs to
> be replaced. (If I recall correctly... it's been a while since I read
> that; maybe this has already been changed in the meantime)
>
> PDF is, OTOH, probably *the* most suited format for getting a uniform
> result whether viewed on the screen or printed on paper.
>
>>
>> But I think people are right: documents are not for technicians
>> like you and
>> me, documents are for people. Must be readble, well formatted,
>> colored and
>> attractive.
>>
>> XSL-FO offer all instruments to create beatiful documents but...
>> you cannot
>> easily integrate them in a desktop application.
>
> That depends on what output format you choose. If you choose RTF,
> then you /can/ edit the end result in MS Word, but you have the
> downside that RTF is not 'Rich' enough to cover every aspect of the
> Recommendation, and due to that, we're again stuck with the
> impossibility to create /the/ XSL-FO document corresponding to /an/ RTF.
>
>> I have used yet FOP during
>> my work, and it was always the final step after a lot of
>> elaboration: the
>> printing/email step.
>>
>> Batik project offers a big support for application integration: the
>> JSVGCanvas class and the SVGGraphics2D generator class. iText offers
>> something similar for PDF... so I think my requirements are not so
>> much far
>> from the "real world".
>
> Indeed, but I think the point is more:
> If one needs a word-processor -> Word or an OO-spinoff
> If you need a WYSIWYG PDF editor -> Acrobat or ...?
> If you need a WYSIWYG FO editor -> Altova, oXygen, Scriptura come to
> mind. If I recall correctly, they all integrate FOP in some way...
> some do it merely by initiating a batch process, but it is possible
> to use only parts of FOP, if one wants.
>
> You are definitely right, that the public API is somewhat limited
> ATM, and the rest of the source code is currently not very friendly
> unless you spend quite a bit of time familiarizing yourself with it.
> There is no easy way to access elements of the FO document on the
> controller layer, as it were. FOP's design is currently based on
> whole-document transformations. We would need quite a bit of changes
> to perform a 'live' atomic re-rendering of a fo:block that is being
> edited, for example.
>
> Currently, there is no completely free FO editor (IIC). Only
> commercial implementations, using a free XSL formatter in the
> background.
>
>> I was seriously thinking to be involved in the enhancement of the
>> AWTViewer,
>> but for now I have no time at all.
>
> That's unfortunate to hear.
>
>> I can imagine the big effort caming from the implementation of the
>> XSL-FO
>> specifications... I absolutely understand you; but, as I repeat,
>> for now I
>> cannot be involved in the FOP project even if I like your proposal
>> very
>> much.
>> Maybe in a close future... who knows?
>
> If so, be sure to direct all your questions/suggestions regarding the
> source code to fop-dev@xmlgraphics.apache.org.
>
>>
>> Anyway, thanks for your sincere opinion and suggestions.
>
> Likewise!
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
-----
Giulio Buccini
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14757378.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jan 10, 2008, at 20:00, Giulio Buccini wrote:
Hi Giulio
> I know: I wrote about MY requirements from MY point view... probably
> everyone have a different view about that and is pretty impossible
> to make
> everybody happy. I understand this...
Of course, but it is always interesting to see those different views
posted here.
Who knows, maybe other users have similar thoughts/needs, but have so
far refrained from speaking up (since they already knew, more or
less, what the answer would be).
> <snip />
> Microsoft Word is massively used inside big organizations, and the
> base
> concept is WYSIWG. So, if you develop a desktop application for an
> employe
> you will receive the -unsolited- question: why what I see on the
> screen is
> not what I see when I print document or when I send it by email? Why
> application cannot show me the final result "in real time" when I
> work on
> data? Word is doing that! (I cannot describe my face in similar
> situations... when I was working for SIEMENS this was one of the most
> frequent questions...)
Sure, and OpenOffice has a word-processor too, and it's also
completely free of any charge.
The big difference with XSL formatters, is that they are not word-
processors, but should rather be compared to web-browsers. A WYSIWYG
XSL-FO application would be much more like an HTML editor, and AFAIK,
in most HTML editors, you don't really edit the page on-the-fly. You
alter the source code, and the document is re-rendered using as much
cached information as possible.
Another huge blocker is that the transformation is far from always
easily reversible. Creating /the/ XSL-FO source for a given PDF
document is impossible, unless the PDF would contain a reference to
it. For a given printed layout, there are always at least a handful
of ways to describe/define it in FO. An XSL-FO document is more
comparable to Tex than to Word's .doc.
Looking at PDF in particular, PDF editors are also not word-
processors. You cannot create a blank document, or alter an existing
one, in the same sense as you would with Word. iText, for example,
mentions in the manual somewhere that you cannot really replace text
in the PDF using the iText API, but you would have to create a new
text box containing the replacement and place that over what needs to
be replaced. (If I recall correctly... it's been a while since I read
that; maybe this has already been changed in the meantime)
PDF is, OTOH, probably *the* most suited format for getting a uniform
result whether viewed on the screen or printed on paper.
>
> But I think people are right: documents are not for technicians
> like you and
> me, documents are for people. Must be readble, well formatted,
> colored and
> attractive.
>
> XSL-FO offer all instruments to create beatiful documents but...
> you cannot
> easily integrate them in a desktop application.
That depends on what output format you choose. If you choose RTF,
then you /can/ edit the end result in MS Word, but you have the
downside that RTF is not 'Rich' enough to cover every aspect of the
Recommendation, and due to that, we're again stuck with the
impossibility to create /the/ XSL-FO document corresponding to /an/ RTF.
> I have used yet FOP during
> my work, and it was always the final step after a lot of
> elaboration: the
> printing/email step.
>
> Batik project offers a big support for application integration: the
> JSVGCanvas class and the SVGGraphics2D generator class. iText offers
> something similar for PDF... so I think my requirements are not so
> much far
> from the "real world".
Indeed, but I think the point is more:
If one needs a word-processor -> Word or an OO-spinoff
If you need a WYSIWYG PDF editor -> Acrobat or ...?
If you need a WYSIWYG FO editor -> Altova, oXygen, Scriptura come to
mind. If I recall correctly, they all integrate FOP in some way...
some do it merely by initiating a batch process, but it is possible
to use only parts of FOP, if one wants.
You are definitely right, that the public API is somewhat limited
ATM, and the rest of the source code is currently not very friendly
unless you spend quite a bit of time familiarizing yourself with it.
There is no easy way to access elements of the FO document on the
controller layer, as it were. FOP's design is currently based on
whole-document transformations. We would need quite a bit of changes
to perform a 'live' atomic re-rendering of a fo:block that is being
edited, for example.
Currently, there is no completely free FO editor (IIC). Only
commercial implementations, using a free XSL formatter in the
background.
> I was seriously thinking to be involved in the enhancement of the
> AWTViewer,
> but for now I have no time at all.
That's unfortunate to hear.
> I can imagine the big effort caming from the implementation of the
> XSL-FO
> specifications... I absolutely understand you; but, as I repeat,
> for now I
> cannot be involved in the FOP project even if I like your proposal
> very
> much.
> Maybe in a close future... who knows?
If so, be sure to direct all your questions/suggestions regarding the
source code to fop-dev@xmlgraphics.apache.org.
>
> Anyway, thanks for your sincere opinion and suggestions.
Likewise!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Giulio Buccini <gi...@libero.it>.
Hello again, Jeremias,
I know: I wrote about MY requirements from MY point view... probably
everyone have a different view about that and is pretty impossible to make
everybody happy. I understand this...
I have designed many informative systems for big companies and "integration
problem" was always the main obstacle in developing: many standards, many
technologies, too many formats. I have used Java SE/EE deeply couse of the
uniform approach and technology integration it offers.
When you work to automatize the business workflow of a large office (for
example a Telecom company department) believe me: you will produce a big
mountain of documents, reports, tables and so on and you must take care
about a detail every forgot from technicians: the HCI - human computer
interface - this is one of the main factors that make a computer system
usable and friendly for the users.
Microsoft Word is massively used inside big organizations, and the base
concept is WYSIWG. So, if you develop a desktop application for an employe
you will receive the -unsolited- question: why what I see on the screen is
not what I see when I print document or when I send it by email? Why
application cannot show me the final result "in real time" when I work on
data? Word is doing that! (I cannot describe my face in similar
situations... when I was working for SIEMENS this was one of the most
frequent questions...)
But I think people are right: documents are not for technicians like you and
me, documents are for people. Must be readble, well formatted, colored and
attractive.
XSL-FO offer all instruments to create beatiful documents but... you cannot
easily integrate them in a desktop application. I have used yet FOP during
my work, and it was always the final step after a lot of elaboration: the
printing/email step.
Batik project offers a big support for application integration: the
JSVGCanvas class and the SVGGraphics2D generator class. iText offers
something similar for PDF... so I think my requirements are not so much far
from the "real world".
I was seriously thinking to be involved in the enhancement of the AWTViewer,
but for now I have no time at all.
I can imagine the big effort caming from the implementation of the XSL-FO
specifications... I absolutely understand you; but, as I repeat, for now I
cannot be involved in the FOP project even if I like your proposal very
much.
Maybe in a close future... who knows?
Anyway, thanks for your sincere opinion and suggestions.
Giulio Buccini
Jeremias Maerki-2 wrote:
>
> These are your requirements for FOP. Most other users don't have these
> requirements so there's no focus in this direction. Yet, anyway. Giulio,
> you're invited to help us improve FOP. Everyone can participate. It
> would be great to have someone who really cares about the
> AWTRenderer/PreviewPanel. AFAIK, it's not something that is used by any
> of the active committers. It was introduced once, improved a little over
> time but it's still just a minimal viewer. I'm sure at least some level
> of interactivity would be relatively easy to implement.
>
> On 10.01.2008 15:32:16 Giulio Buccini wrote:
>>
>> Hello Jeremias,
>>
>> I apologyze, you're right: PreviewPanel is a renderer of the FO document,
>> not of the PDF document.
>>
>> Nevertheless, as I understand, FOP was designed mainly to realize a
>> software
>> the is used mainly in off-line mode. Beleive me, FOP is great, but it
>> cannot
>> be used easily for integration in real-world application.
>
> Uhm, in your real-world application anyway. Do you know how many users
> use FOP in real-world scenarios?
>
>> The main lack of FOP is the follow: it doesn't provide API to manipulate
>> and
>> support interaction with a user. I adore FOP, but it can be used only in
>> pipe-processing, scriptings, batch and so on.
>
> The project is defined to produce a formatter, not necessarily a
> document viewer. The AWT Viewer is just a goodie we've got somewhere on
> the way by a contributor. It's not a central part of FOP.
>
>> I think there is a lot of people (like me) interested in a easy-to-use
>> API
>> to develop real solutions using the XSL-FO standard. From my point view
>> FOP
>> is too much close to a "compiler" (!!) : give-it the XSL-FO code and it
>> will
>> give you something useful (PDF for example). The point is: java is
>> powerful
>> language and it allows sophisticate levels of abstraction, so why I must
>> code XSL-FO directly?
>
> Sorry, but I don't follow you here.
>
>> I think that the major part of people is using FOP as a sort of
>> transcoder
>> routine. Understand me, this is a big result di per se, but I think more
>> success can be achieved if FOP is completed with a set of useful software
>> tools for composition, manipulation, interaction, browsing and so on. Do
>> you
>> agree?
>
> Sure, that would be cool. But we're struggling enough to cover enough of
> the XSL-FO specification in the first place. The question is: Can you
> help us?
>
>> Even SVG is supporting features like a simple mouse-click...
>>
>> Returning to your point, there are not so much free PDF viewer
>> implemented
>> in Java. Most of them are becomed commercial products while the others
>> are
>> really poor and bad implemented.
>> I have adopted the JPedal Standard implementation (the one that is free):
>> no
>> documentation but a terrible simple application used as reference for
>> free-users (it seems like an old old old old C code translated in java -
>> can
>> you imagine what a mess?? Mamma mia!).
>>
>> I'm doing on the PDFDecoder class of JPedal exactly the same kind of work
>> that you have suggested for the AWTRenderer: a lot of heavy
>> personalization
>> and implementation of basic user features (goToPage, scrollToBokkmark,
>> zomm
>> in/out and so on).
>>
>> Maybe was better trying to personalize the AWTRenderer, but main problem
>> is
>> lack of documentation: I have no-idea on how the AWT renderer is working
>> internally; there is no a code example or a simple application. So I
>> don't
>> have a minimal base for starting implementation.
>
> The preview is so special and not in wide-spread use that there's is not
> a big set of examples. You'll have to figure out how things work from
> the source code. Start from the command-line (-awt parameter) and find
> out how the preview is constructed. It would be great if you document
> your findings on FOP's Wiki.
>
>> I hope in future, FOP project, will go in the right direction: more
>> usability, sophisticated high-level APIs, details hiding.
>
> Unless you put your energy in this, I don't think it will. Sorry. Open
> Source is developed in the directions the development team steers it.
> And you can be part of it.
>
>> Sincerely, Giulio Buccini.
>>
>>
>> Jeremias Maerki-2 wrote:
>> >
>> > Just a second, I think you're mixing things: PreviewPanel is not a "PDF
>> > view". It's displaying the rendered document using Java2D/AWT. The PDF
>> > format is not involved at all.
>> >
>> > To your problem: If you switched to PDF (instead of PreviewPanel), i.e.
>> > embed a PDF-capable browser (or Acrobat Reader directly) in your Swing
>> > application you could make use of PDF named destinations like the
>> > anchors in HTML. This is done using the fox:destination extension
>> > element (which I just noticed is not documented anymore although it has
>> > been reimplemented in the latest release, but I'll fix that right
>> away).
>> >
>> > How a browser or Acrobat Reader is embedded in a Swing application I
>> > can't tell you off-hand but I'm sure there are solutions on the web
>> > somewhere. I've done it in SWT once where it's certainly easier. But
>> the
>> > whole thing could become platform-dependent that way which is bad.
>> >
>> > So the platform-independent solution would be to teach the AWTRenderer
>> > (which is used to display the rendered document in PreviewPanel) to
>> > process the named destination elements to keep a list of the
>> > anchors/named destinations. You could then let the PreviewPanel jump to
>> > the right place.
>> >
>> > I hope that gives you a few first pointers where you can go.
>> >
>> > On 27.12.2007 17:37:27 Giulio Buccini wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm developing a java stand-alone application structured on the screen
>> as
>> >> follows:
>> >>
>> >> 1) a tree data structure on the left side of the screen (a JTree
>> >> essentially);
>> >>
>> >> 2) a pdf view of tree data on the right side of the screen.
>> >>
>> >> My target is to provide a clear view of the final pdf document to the
>> >> user.
>> >> FOP code is re-generated after any data modification (add, remove,
>> edit
>> >> and
>> >> so on) operated on the tree.
>> >>
>> >> I'm migrating my application from an HTML view to a PDF view cause of
>> >> terrible troubles rising up when HTML is printed on a A4-size paper.
>> >>
>> >> As I understand, the only component that I can use to embed a PDF view
>> in
>> >> my
>> >> application is the PreviewPanel. Nevertheless, this component is very
>> >> limited: user can only jump across pages.
>> >>
>> >> What I need is a trick or a workaround to implement following
>> behaviour:
>> >>
>> >> "When user click on a element in the tree the preview panel
>> automatically
>> >> jumps to the right page and scroll to right place."
>> >>
>> >> Somebody knows a workaround to make this possible?
>> >>
>> >> In my old html-version of my application I have solved this problem by
>> >> inserting many hidden anchor elements in the HTML code and using the
>> >> "scrollToLink" method of the JDesktop pane component. Now I'm in
>> troubles
>> >> cause I cannot apply the same solution with the generated pdf
>> document...
>> >>
>> >> Suggestions? Ideas?
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html
>> >> Sent from the FOP - Users mailing list archive at Nabble.com.
>> >
>> >
>> >
>> > Jeremias Maerki
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> >
>> >
>> >
>>
>>
>> -----
>> Giulio Buccini
>> --
>> View this message in context:
>> http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14734907.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
-----
Giulio Buccini
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14741182.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
These are your requirements for FOP. Most other users don't have these
requirements so there's no focus in this direction. Yet, anyway. Giulio,
you're invited to help us improve FOP. Everyone can participate. It
would be great to have someone who really cares about the
AWTRenderer/PreviewPanel. AFAIK, it's not something that is used by any
of the active committers. It was introduced once, improved a little over
time but it's still just a minimal viewer. I'm sure at least some level
of interactivity would be relatively easy to implement.
On 10.01.2008 15:32:16 Giulio Buccini wrote:
>
> Hello Jeremias,
>
> I apologyze, you're right: PreviewPanel is a renderer of the FO document,
> not of the PDF document.
>
> Nevertheless, as I understand, FOP was designed mainly to realize a software
> the is used mainly in off-line mode. Beleive me, FOP is great, but it cannot
> be used easily for integration in real-world application.
Uhm, in your real-world application anyway. Do you know how many users
use FOP in real-world scenarios?
> The main lack of FOP is the follow: it doesn't provide API to manipulate and
> support interaction with a user. I adore FOP, but it can be used only in
> pipe-processing, scriptings, batch and so on.
The project is defined to produce a formatter, not necessarily a
document viewer. The AWT Viewer is just a goodie we've got somewhere on
the way by a contributor. It's not a central part of FOP.
> I think there is a lot of people (like me) interested in a easy-to-use API
> to develop real solutions using the XSL-FO standard. From my point view FOP
> is too much close to a "compiler" (!!) : give-it the XSL-FO code and it will
> give you something useful (PDF for example). The point is: java is powerful
> language and it allows sophisticate levels of abstraction, so why I must
> code XSL-FO directly?
Sorry, but I don't follow you here.
> I think that the major part of people is using FOP as a sort of transcoder
> routine. Understand me, this is a big result di per se, but I think more
> success can be achieved if FOP is completed with a set of useful software
> tools for composition, manipulation, interaction, browsing and so on. Do you
> agree?
Sure, that would be cool. But we're struggling enough to cover enough of
the XSL-FO specification in the first place. The question is: Can you
help us?
> Even SVG is supporting features like a simple mouse-click...
>
> Returning to your point, there are not so much free PDF viewer implemented
> in Java. Most of them are becomed commercial products while the others are
> really poor and bad implemented.
> I have adopted the JPedal Standard implementation (the one that is free): no
> documentation but a terrible simple application used as reference for
> free-users (it seems like an old old old old C code translated in java - can
> you imagine what a mess?? Mamma mia!).
>
> I'm doing on the PDFDecoder class of JPedal exactly the same kind of work
> that you have suggested for the AWTRenderer: a lot of heavy personalization
> and implementation of basic user features (goToPage, scrollToBokkmark, zomm
> in/out and so on).
>
> Maybe was better trying to personalize the AWTRenderer, but main problem is
> lack of documentation: I have no-idea on how the AWT renderer is working
> internally; there is no a code example or a simple application. So I don't
> have a minimal base for starting implementation.
The preview is so special and not in wide-spread use that there's is not
a big set of examples. You'll have to figure out how things work from
the source code. Start from the command-line (-awt parameter) and find
out how the preview is constructed. It would be great if you document
your findings on FOP's Wiki.
> I hope in future, FOP project, will go in the right direction: more
> usability, sophisticated high-level APIs, details hiding.
Unless you put your energy in this, I don't think it will. Sorry. Open
Source is developed in the directions the development team steers it.
And you can be part of it.
> Sincerely, Giulio Buccini.
>
>
> Jeremias Maerki-2 wrote:
> >
> > Just a second, I think you're mixing things: PreviewPanel is not a "PDF
> > view". It's displaying the rendered document using Java2D/AWT. The PDF
> > format is not involved at all.
> >
> > To your problem: If you switched to PDF (instead of PreviewPanel), i.e.
> > embed a PDF-capable browser (or Acrobat Reader directly) in your Swing
> > application you could make use of PDF named destinations like the
> > anchors in HTML. This is done using the fox:destination extension
> > element (which I just noticed is not documented anymore although it has
> > been reimplemented in the latest release, but I'll fix that right away).
> >
> > How a browser or Acrobat Reader is embedded in a Swing application I
> > can't tell you off-hand but I'm sure there are solutions on the web
> > somewhere. I've done it in SWT once where it's certainly easier. But the
> > whole thing could become platform-dependent that way which is bad.
> >
> > So the platform-independent solution would be to teach the AWTRenderer
> > (which is used to display the rendered document in PreviewPanel) to
> > process the named destination elements to keep a list of the
> > anchors/named destinations. You could then let the PreviewPanel jump to
> > the right place.
> >
> > I hope that gives you a few first pointers where you can go.
> >
> > On 27.12.2007 17:37:27 Giulio Buccini wrote:
> >>
> >> Hi,
> >>
> >> I'm developing a java stand-alone application structured on the screen as
> >> follows:
> >>
> >> 1) a tree data structure on the left side of the screen (a JTree
> >> essentially);
> >>
> >> 2) a pdf view of tree data on the right side of the screen.
> >>
> >> My target is to provide a clear view of the final pdf document to the
> >> user.
> >> FOP code is re-generated after any data modification (add, remove, edit
> >> and
> >> so on) operated on the tree.
> >>
> >> I'm migrating my application from an HTML view to a PDF view cause of
> >> terrible troubles rising up when HTML is printed on a A4-size paper.
> >>
> >> As I understand, the only component that I can use to embed a PDF view in
> >> my
> >> application is the PreviewPanel. Nevertheless, this component is very
> >> limited: user can only jump across pages.
> >>
> >> What I need is a trick or a workaround to implement following behaviour:
> >>
> >> "When user click on a element in the tree the preview panel automatically
> >> jumps to the right page and scroll to right place."
> >>
> >> Somebody knows a workaround to make this possible?
> >>
> >> In my old html-version of my application I have solved this problem by
> >> inserting many hidden anchor elements in the HTML code and using the
> >> "scrollToLink" method of the JDesktop pane component. Now I'm in troubles
> >> cause I cannot apply the same solution with the generated pdf document...
> >>
> >> Suggestions? Ideas?
> >>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html
> >> Sent from the FOP - Users mailing list archive at Nabble.com.
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> >
>
>
> -----
> Giulio Buccini
> --
> View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14734907.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Giulio Buccini <gi...@libero.it>.
Hi Benjamin,
I know that viewer, I have spent one week on Internet searching for an easy
integrable pdf viewer. I have spent so much time in this research that my
wife tolds me: "are you searching for a lover???" :) :)
pdf-render is not a real API to integrate a pdf-view into your application.
Is just what it states: a pdf-viewer application, not an API "for pdf view
integration". Do you understand the point?
The project is a little stand-alone java application. Can you imagine how
many nights you must spend to understand all inner details and modify the
viewer behaviour to meet needs of your own application?
Yes, it can be done, but I have calculated that the effort is comparable to
write your API from the scratch (!!!).
If you want to "fight" with javadocs you wil find (in any pdf library, not
only in the pdf-viewer project) a huge list of methods named like:
"setYYY", "setKKK"
and description is something like:
"this method set the YYY value, this method sets the KKK value...." and so
on.
Wao! Is a great help for me! :)
Honestly speaking, integrating a such that implementation in your
application can become a nightmare.
I really don't understand why programmers in this project don't want spend
time in producing documentation, I really don't understand why. There is a
common behaviour in all free-project community: time spent on documentation
is lost time. Nothing can be more wrong: if you don't comunicate the general
overview of the architecture of your solution how I can fully understand
potential features of that solutions?
When I take a look at that projects I saw only a list of cryptic methods.
Italian says: "my face looks like the one of the cow watching the train
running..." :) :) (I hope translation is right)
The pdf-render project has very poor documentation... no tutorials, no UML
diagrams, no specification documents. What pdf-renderer project offers is:
1 example on how open a pdf;
1 example on how draw an image;
11 short messages in the mailing list...
Really you think this is a good project???
On the counterwise, JPedal offer a complete application example (even
terrible, hostic, cryptic).
Anyway really thanks, for your suggestion. I have appreciated it.
Sincerely, Giulio Buccini.
Benjamin Wohlwend wrote:
>
> Hi,
>
>
> Giulio Buccini wrote:
>>
>> Returning to your point, there are not so much free PDF viewer
>> implemented in Java. Most of them are becomed commercial products while
>> the others are really poor and bad implemented.
>> I have adopted the JPedal Standard implementation (the one that is free):
>> no documentation but a terrible simple application used as reference for
>> free-users (it seems like an old old old old C code translated in java -
>> can you imagine what a mess?? Mamma mia!).
>>
>
> I don't know if it helps, but Sun released a free (LGPL) PDF renderer a
> few weeks ago. It is implemented completely in Java, you can render the
> document on arbitrary Swing components, on a Graphics2D context or in an
> image. I don't know if the API is reasonable, but the examples look quite
> straight forward.
>
> https://pdf-renderer.dev.java.net/
>
> Kind regards,
>
> Benjamin Wohlwend
>
-----
Giulio Buccini
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14753938.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Benjamin Wohlwend <bw...@piquadrat.ch>.
Hi,
Giulio Buccini wrote:
>
> Returning to your point, there are not so much free PDF viewer implemented
> in Java. Most of them are becomed commercial products while the others are
> really poor and bad implemented.
> I have adopted the JPedal Standard implementation (the one that is free):
> no documentation but a terrible simple application used as reference for
> free-users (it seems like an old old old old C code translated in java -
> can you imagine what a mess?? Mamma mia!).
>
I don't know if it helps, but Sun released a free (LGPL) PDF renderer a few
weeks ago. It is implemented completely in Java, you can render the document
on arbitrary Swing components, on a Graphics2D context or in an image. I
don't know if the API is reasonable, but the examples look quite straight
forward.
https://pdf-renderer.dev.java.net/
Kind regards,
Benjamin Wohlwend
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14743247.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Giulio Buccini <gi...@libero.it>.
Hello Jeremias,
I apologyze, you're right: PreviewPanel is a renderer of the FO document,
not of the PDF document.
Nevertheless, as I understand, FOP was designed mainly to realize a software
the is used mainly in off-line mode. Beleive me, FOP is great, but it cannot
be used easily for integration in real-world application.
The main lack of FOP is the follow: it doesn't provide API to manipulate and
support interaction with a user. I adore FOP, but it can be used only in
pipe-processing, scriptings, batch and so on.
I think there is a lot of people (like me) interested in a easy-to-use API
to develop real solutions using the XSL-FO standard. From my point view FOP
is too much close to a "compiler" (!!) : give-it the XSL-FO code and it will
give you something useful (PDF for example). The point is: java is powerful
language and it allows sophisticate levels of abstraction, so why I must
code XSL-FO directly?
I think that the major part of people is using FOP as a sort of transcoder
routine. Understand me, this is a big result di per se, but I think more
success can be achieved if FOP is completed with a set of useful software
tools for composition, manipulation, interaction, browsing and so on. Do you
agree?
Even SVG is supporting features like a simple mouse-click...
Returning to your point, there are not so much free PDF viewer implemented
in Java. Most of them are becomed commercial products while the others are
really poor and bad implemented.
I have adopted the JPedal Standard implementation (the one that is free): no
documentation but a terrible simple application used as reference for
free-users (it seems like an old old old old C code translated in java - can
you imagine what a mess?? Mamma mia!).
I'm doing on the PDFDecoder class of JPedal exactly the same kind of work
that you have suggested for the AWTRenderer: a lot of heavy personalization
and implementation of basic user features (goToPage, scrollToBokkmark, zomm
in/out and so on).
Maybe was better trying to personalize the AWTRenderer, but main problem is
lack of documentation: I have no-idea on how the AWT renderer is working
internally; there is no a code example or a simple application. So I don't
have a minimal base for starting implementation.
I hope in future, FOP project, will go in the right direction: more
usability, sophisticated high-level APIs, details hiding.
Sincerely, Giulio Buccini.
Jeremias Maerki-2 wrote:
>
> Just a second, I think you're mixing things: PreviewPanel is not a "PDF
> view". It's displaying the rendered document using Java2D/AWT. The PDF
> format is not involved at all.
>
> To your problem: If you switched to PDF (instead of PreviewPanel), i.e.
> embed a PDF-capable browser (or Acrobat Reader directly) in your Swing
> application you could make use of PDF named destinations like the
> anchors in HTML. This is done using the fox:destination extension
> element (which I just noticed is not documented anymore although it has
> been reimplemented in the latest release, but I'll fix that right away).
>
> How a browser or Acrobat Reader is embedded in a Swing application I
> can't tell you off-hand but I'm sure there are solutions on the web
> somewhere. I've done it in SWT once where it's certainly easier. But the
> whole thing could become platform-dependent that way which is bad.
>
> So the platform-independent solution would be to teach the AWTRenderer
> (which is used to display the rendered document in PreviewPanel) to
> process the named destination elements to keep a list of the
> anchors/named destinations. You could then let the PreviewPanel jump to
> the right place.
>
> I hope that gives you a few first pointers where you can go.
>
> On 27.12.2007 17:37:27 Giulio Buccini wrote:
>>
>> Hi,
>>
>> I'm developing a java stand-alone application structured on the screen as
>> follows:
>>
>> 1) a tree data structure on the left side of the screen (a JTree
>> essentially);
>>
>> 2) a pdf view of tree data on the right side of the screen.
>>
>> My target is to provide a clear view of the final pdf document to the
>> user.
>> FOP code is re-generated after any data modification (add, remove, edit
>> and
>> so on) operated on the tree.
>>
>> I'm migrating my application from an HTML view to a PDF view cause of
>> terrible troubles rising up when HTML is printed on a A4-size paper.
>>
>> As I understand, the only component that I can use to embed a PDF view in
>> my
>> application is the PreviewPanel. Nevertheless, this component is very
>> limited: user can only jump across pages.
>>
>> What I need is a trick or a workaround to implement following behaviour:
>>
>> "When user click on a element in the tree the preview panel automatically
>> jumps to the right page and scroll to right place."
>>
>> Somebody knows a workaround to make this possible?
>>
>> In my old html-version of my application I have solved this problem by
>> inserting many hidden anchor elements in the HTML code and using the
>> "scrollToLink" method of the JDesktop pane component. Now I'm in troubles
>> cause I cannot apply the same solution with the generated pdf document...
>>
>> Suggestions? Ideas?
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
-----
Giulio Buccini
--
View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14734907.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: How navigate/scroll inside the PreviewPanel
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Just a second, I think you're mixing things: PreviewPanel is not a "PDF
view". It's displaying the rendered document using Java2D/AWT. The PDF
format is not involved at all.
To your problem: If you switched to PDF (instead of PreviewPanel), i.e.
embed a PDF-capable browser (or Acrobat Reader directly) in your Swing
application you could make use of PDF named destinations like the
anchors in HTML. This is done using the fox:destination extension
element (which I just noticed is not documented anymore although it has
been reimplemented in the latest release, but I'll fix that right away).
How a browser or Acrobat Reader is embedded in a Swing application I
can't tell you off-hand but I'm sure there are solutions on the web
somewhere. I've done it in SWT once where it's certainly easier. But the
whole thing could become platform-dependent that way which is bad.
So the platform-independent solution would be to teach the AWTRenderer
(which is used to display the rendered document in PreviewPanel) to
process the named destination elements to keep a list of the
anchors/named destinations. You could then let the PreviewPanel jump to
the right place.
I hope that gives you a few first pointers where you can go.
On 27.12.2007 17:37:27 Giulio Buccini wrote:
>
> Hi,
>
> I'm developing a java stand-alone application structured on the screen as
> follows:
>
> 1) a tree data structure on the left side of the screen (a JTree
> essentially);
>
> 2) a pdf view of tree data on the right side of the screen.
>
> My target is to provide a clear view of the final pdf document to the user.
> FOP code is re-generated after any data modification (add, remove, edit and
> so on) operated on the tree.
>
> I'm migrating my application from an HTML view to a PDF view cause of
> terrible troubles rising up when HTML is printed on a A4-size paper.
>
> As I understand, the only component that I can use to embed a PDF view in my
> application is the PreviewPanel. Nevertheless, this component is very
> limited: user can only jump across pages.
>
> What I need is a trick or a workaround to implement following behaviour:
>
> "When user click on a element in the tree the preview panel automatically
> jumps to the right page and scroll to right place."
>
> Somebody knows a workaround to make this possible?
>
> In my old html-version of my application I have solved this problem by
> inserting many hidden anchor elements in the HTML code and using the
> "scrollToLink" method of the JDesktop pane component. Now I'm in troubles
> cause I cannot apply the same solution with the generated pdf document...
>
> Suggestions? Ideas?
>
>
> --
> View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org