Re: How navigate/scroll inside the PreviewPanel

2008-01-11 Thread Giulio Buccini
 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 [EMAIL PROTECTED]
 

 Anyway, thanks for your sincere opinion and suggestions.
 
 Likewise!
 
 Cheers
 
 Andreas
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How navigate/scroll inside the PreviewPanel

2008-01-11 Thread Giulio Buccini

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How navigate/scroll inside the PreviewPanel

2008-01-10 Thread Giulio Buccini
 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How navigate/scroll inside the PreviewPanel

2008-01-10 Thread Jeremias Maerki
 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
 
 -
 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How navigate/scroll inside the PreviewPanel

2008-01-10 Thread Giulio Buccini
, 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
 
 -
 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

Re: How navigate/scroll inside the PreviewPanel

2008-01-10 Thread Benjamin Wohlwend

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How navigate/scroll inside the PreviewPanel

2008-01-10 Thread Andreas L Delmelle

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 

Re: How navigate/scroll inside the PreviewPanel

2008-01-07 Thread Jeremias Maerki
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]