RE: [PDF Viewer] Utility request
Heh...just give me some time. We might get Java 1.1 compatibility dynamically loaded yet. ;) -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 7:44 PM To: [EMAIL PROTECTED] Subject: Re: [PDF Viewer] Utility request Victor, The IAC, by this account, only has support for Macintosh and DDE/OLE on WIndows. While some work on support for OLE 2 document formats has been done in the Jakarta POI project, I don't know that this will solve the problem of cross-platform support for the project you have in mind. If it's not x-platform, it violates one of basic assumptions of the Apache XML efforts (although users without access to Java 2 may raise their eyebrows at that.) Peter Victor Mote wrote: > Ralph LaChance wrote: > > <-Start-> > Last time I used the Acrobat SDK (1999) it provided support only building a > plug-in to Acrobat Exchange (not free) - ie. adding functionality to > Exchange itself -- things like specialized searching, indexing, or > retrieving simple objects (including text) from the file, adding work flow, > modifying Exchange's menus etc. It provided NO support for rendering per se, > and, more importantly, had almost no support for modifying the (free) > Reader. > > Whether one could use a plug-in as a vehicle for tightly bolting acrobat > exchange is an interesting concept, but (in my opinion) we'd not have any > chance to doing anything useful with the reader. > <-End-> > > Paragraph 1, Chapter 1 of the Core_API/CoreAPIOverview.pdf document in the > Acrobat 5 SDK doc says: > > <-Start-> > The Acrobat core API is a set of interfaces you can use to write plug-ins > that integrate with Acrobat and Acrobat Reader. This chapter introduces the > core API, describing its object orientation and organization, and a number > of other concepts fundamental to understanding the API. > > Ways to Integrate With the Acrobat Viewers > You can develop software that integrates with Acrobat and Acrobat Reader in > two ways: > * By creating plug-ins that are dynamically linked to the Acrobat viewer and > extend the viewer's functionality > * By writing a separate application process that uses interapplication > communication (IAC) to control Acrobat functionality. DDE and OLE are > supported on Windows and Apple events / AppleScript on the Macintosh. > <-End-> > > There is a separate InterApplication_Communication folder containing related > documents. Again, I haven't done it, so maybe it is all theory that doesn't > work for the application at hand. And I don't mean to be argumentative -- it > just seems that writing a good PDF viewer would be a big enough task that I > would want to exhaust other possibilities before heading down that path. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Victor, FOP has no control over any downstream uses of generated PDF, clearly. Any project that works with the PDF is logically independent of FOP, so it would belong in a separate project, as you suggest. It would be unfortunate if folks got the idea that FOP was somehow more fully realised in a Windows/Mac environment. I may be drawing a long bow in saying that x-platform accessibility is a basic assumption of the XML sub-projects. It just seems to have panned out that way, and I'm pleased about that. Peter Victor Mote wrote: > Peter: > > If FOP has some obligation to support any downstream use of its output in a > cross-platform way, then that is a pretty tall order. I guess in my mind > getting the file into cross-platform PDF format is sufficient. I don't have > more than an intuitive grasp of the "basic assumptions of the Apache XML > efforts", but rendering PDFs would violate my understanding of that concept > simply because it ain't XML (support for structure in recent PDF versions > notwithstanding). IMHO, if it is needed at all, it probably belongs in a > separate project. I like the proposed solution of fixing / completing the > FOP Area Viewer much better. (Please count my newbie vote at less than 1% of > the value of the real contributors.) -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Peter B. West wrote: > > Victor, > > The IAC, by this account, only has support for Macintosh and DDE/OLE on > WIndows. While some work on support for OLE 2 document formats has been > done in the Jakarta POI project, I don't know that this will solve the > problem of cross-platform support for the project you have in mind. If > it's not x-platform, it violates one of basic assumptions of the Apache > XML efforts (although users without access to Java 2 may raise their > eyebrows at that.) > > Peter > Peter: If FOP has some obligation to support any downstream use of its output in a cross-platform way, then that is a pretty tall order. I guess in my mind getting the file into cross-platform PDF format is sufficient. I don't have more than an intuitive grasp of the "basic assumptions of the Apache XML efforts", but rendering PDFs would violate my understanding of that concept simply because it ain't XML (support for structure in recent PDF versions notwithstanding). IMHO, if it is needed at all, it probably belongs in a separate project. I like the proposed solution of fixing / completing the FOP Area Viewer much better. (Please count my newbie vote at less than 1% of the value of the real contributors.) Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Victor, The IAC, by this account, only has support for Macintosh and DDE/OLE on WIndows. While some work on support for OLE 2 document formats has been done in the Jakarta POI project, I don't know that this will solve the problem of cross-platform support for the project you have in mind. If it's not x-platform, it violates one of basic assumptions of the Apache XML efforts (although users without access to Java 2 may raise their eyebrows at that.) Peter Victor Mote wrote: > Ralph LaChance wrote: > > <-Start-> > Last time I used the Acrobat SDK (1999) it provided support only building a > plug-in to Acrobat Exchange (not free) - ie. adding functionality to > Exchange itself -- things like specialized searching, indexing, or > retrieving simple objects (including text) from the file, adding work flow, > modifying Exchange's menus etc. It provided NO support for rendering per se, > and, more importantly, had almost no support for modifying the (free) > Reader. > > Whether one could use a plug-in as a vehicle for tightly bolting acrobat > exchange is an interesting concept, but (in my opinion) we'd not have any > chance to doing anything useful with the reader. > <-End-> > > Paragraph 1, Chapter 1 of the Core_API/CoreAPIOverview.pdf document in the > Acrobat 5 SDK doc says: > > <-Start-> > The Acrobat core API is a set of interfaces you can use to write plug-ins > that integrate with Acrobat and Acrobat Reader. This chapter introduces the > core API, describing its object orientation and organization, and a number > of other concepts fundamental to understanding the API. > > Ways to Integrate With the Acrobat Viewers > You can develop software that integrates with Acrobat and Acrobat Reader in > two ways: > * By creating plug-ins that are dynamically linked to the Acrobat viewer and > extend the viewer's functionality > * By writing a separate application process that uses interapplication > communication (IAC) to control Acrobat functionality. DDE and OLE are > supported on Windows and Apple events / AppleScript on the Macintosh. > <-End-> > > There is a separate InterApplication_Communication folder containing related > documents. Again, I haven't done it, so maybe it is all theory that doesn't > work for the application at hand. And I don't mean to be argumentative -- it > just seems that writing a good PDF viewer would be a big enough task that I > would want to exhaust other possibilities before heading down that path. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Keiron Liddle wrote: > (One day I will convince someone to help out with HEAD code) The problem here is that HEAD is nearly as much of a mess as the maintenance branch, with the unfortunate disadvantage that it doesn't work. I'd rather put work into something which can be downloaded and compiled (i.e. fixes problems I have *now*). Actually, I have quite a few ideas how to fix many deficits in the maintenance branch (properties, TR14, whitespace handling, line height computation, inline areas, inline containers, links...), unfortunately, I don't have as much time... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Ralph LaChance wrote: <-Start-> Last time I used the Acrobat SDK (1999) it provided support only building a plug-in to Acrobat Exchange (not free) - ie. adding functionality to Exchange itself -- things like specialized searching, indexing, or retrieving simple objects (including text) from the file, adding work flow, modifying Exchange's menus etc. It provided NO support for rendering per se, and, more importantly, had almost no support for modifying the (free) Reader. Whether one could use a plug-in as a vehicle for tightly bolting acrobat exchange is an interesting concept, but (in my opinion) we'd not have any chance to doing anything useful with the reader. <-End-> Paragraph 1, Chapter 1 of the Core_API/CoreAPIOverview.pdf document in the Acrobat 5 SDK doc says: <-Start-> The Acrobat core API is a set of interfaces you can use to write plug-ins that integrate with Acrobat and Acrobat Reader. This chapter introduces the core API, describing its object orientation and organization, and a number of other concepts fundamental to understanding the API. Ways to Integrate With the Acrobat Viewers You can develop software that integrates with Acrobat and Acrobat Reader in two ways: * By creating plug-ins that are dynamically linked to the Acrobat viewer and extend the viewer's functionality * By writing a separate application process that uses interapplication communication (IAC) to control Acrobat functionality. DDE and OLE are supported on Windows and Apple events / AppleScript on the Macintosh. <-End-> There is a separate InterApplication_Communication folder containing related documents. Again, I haven't done it, so maybe it is all theory that doesn't work for the application at hand. And I don't mean to be argumentative -- it just seems that writing a good PDF viewer would be a big enough task that I would want to exhaust other possibilities before heading down that path. Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Or would optionally need caching services that fit the "unsigned" security model. For example, applets could cache to their servers. -Original Message- From: Jim Urban [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 8:46 AM To: [EMAIL PROTECTED] Subject: RE: [PDF Viewer] Utility request > - allow pages to be saved to disk to reduce memory This should be optional. Otherwise applets and JWS applications will need to be signed in order to run. Jim Urban - [EMAIL PROTECTED] Park City Solutions Inc. Clinical Connectivity Suite Product Manager Suite 295 500 Park Blvd. Itasca, IL 60143 Voice: (630) 250-3045 x106 Fax: (630) 250-3046 CONFIDENTIALITY NOTICE This message and any included attachments are from Park City Solutions Inc. and are intended only for the entity to which it is addressed. The contained information is confidential and privileged material. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error please notify the sender of the delivery error by e-mail or call Park City Solutions Inc. corporate offices at (435) 654-0621 -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 4:53 AM To: FOP Subject: RE: [PDF Viewer] Utility request On Mon, 2002-07-29 at 11:40, RamanaJV wrote: > Ralph, > Your idea of "Fixing the awt renderer" is the correct one. After a > deep thought, I too came to the conclusion that instead of writing a PDF > renderer, if we can tune up the AWT renderer, it will be great. The main > problem with AWT renderer now is the heavy memory it uses. We need to find > the source of memory drain and tune it. Heavy memory use: - holds onto every page in memory - area tree holds onto fo tree - all images are also held in the area tree and image factory - in general far too much memory is used for many structures Solutions: - separate area tree from fo tree - allow pages to be saved to disk to reduce memory - improve image handling The design for this is mostly implemented in HEAD. (One day I will convince someone to help out with HEAD code) > We need to come up with the basic plan for this. Also, we have to > first look and summarize the current issues with AWT renderer and step > accordingly. > > Ramana. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
> - allow pages to be saved to disk to reduce memory This should be optional. Otherwise applets and JWS applications will need to be signed in order to run. Jim Urban - [EMAIL PROTECTED] Park City Solutions Inc. Clinical Connectivity Suite Product Manager Suite 295 500 Park Blvd. Itasca, IL 60143 Voice: (630) 250-3045 x106 Fax: (630) 250-3046 CONFIDENTIALITY NOTICE This message and any included attachments are from Park City Solutions Inc. and are intended only for the entity to which it is addressed. The contained information is confidential and privileged material. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error please notify the sender of the delivery error by e-mail or call Park City Solutions Inc. corporate offices at (435) 654-0621 -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 4:53 AM To: FOP Subject: RE: [PDF Viewer] Utility request On Mon, 2002-07-29 at 11:40, RamanaJV wrote: > Ralph, > Your idea of "Fixing the awt renderer" is the correct one. After a > deep thought, I too came to the conclusion that instead of writing a PDF > renderer, if we can tune up the AWT renderer, it will be great. The main > problem with AWT renderer now is the heavy memory it uses. We need to find > the source of memory drain and tune it. Heavy memory use: - holds onto every page in memory - area tree holds onto fo tree - all images are also held in the area tree and image factory - in general far too much memory is used for many structures Solutions: - separate area tree from fo tree - allow pages to be saved to disk to reduce memory - improve image handling The design for this is mostly implemented in HEAD. (One day I will convince someone to help out with HEAD code) > We need to come up with the basic plan for this. Also, we have to > first look and summarize the current issues with AWT renderer and step > accordingly. > > Ramana. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
At 06:01 AM 7/29/02, I wrote: >Anyone volunteering to profile awt's memory usage ? Dumb comment. Sorry - Keiron's got the right answer ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
yes. Anyone volunteering to profile awt's memory usage ? At 05:40 AM 7/29/02, Ramana wrote: > >Ralph, > Your idea of "Fixing the awt renderer" is the correct one. After a >deep thought, I too came to the conclusion that instead of writing a PDF >renderer, if we can tune up the AWT renderer, it will be great. The main >problem with AWT renderer now is the heavy memory it uses. We need to find >the source of memory drain and tune it. > We need to come up with the basic plan for this. Also, we have to >first look and summarize the current issues with AWT renderer and step >accordingly. > >Ramana. > > > >-Original Message- >From: Ralph LaChance [mailto:[EMAIL PROTECTED]] >Sent: Monday, July 29, 2002 3:06 PM >To: [EMAIL PROTECTED] >Subject: Re: [PDF Viewer] Utility request > > >I agree with Oleg's last sentencetotally - which I translate roughly to >"lets fix the >awt renderer" > >In fact, I'd add a 3rd (or 2 1/2) user - the one who wishes to go directly >from >xml to a printer via fop. > >My colleagues here and I have inserted several changes to tweak spacings, >borders, >and so on over the past two years, and several other contributors have >refined the awt renderer over even more. > >Recently, I got stumped by a problem in that java's font engine rasterizes >glyphs >differently depending on whether the target was the on-screen graphics >context >or a printer context. (see archives) - anyone who could help unsnarl that >mess >would be making a noteworthy contribution. > >At 07:59 AM 7/28/02, you wrote: > >Matthew L. Avizinis wrote: > > It might also be helpful to recognize that as FOP becomes more popular >there > >>are distinctly _two_ groups of "users" emerging. The first group has been > >>using FOP from the beginning and those are the Java developers who use FOP > >>to create some other end product. Recently I've noticed that there are >more > >>people attempting to use FOP who are simply people who want to use FOP as >an > >>end product (more of an FO viewer) and want it to fulfill the role of a > >>product like X-Smiles (which unfortunately still falls far short of its >goal > >>of being a good FO viewer). > > > >I believe AWT previewer someday in the future will become some kind of FO > >IDE and afaik even nowadays somebody in the team has something to donate. > > > >-- > >Oleg Tkachenko > >Multiconn International, Israel > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, email: [EMAIL PROTECTED] > > > ' Best, > -Ralph LaChance > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
At 01:33 PM 7/28/02, you wrote: >If it helps any, Adobe has a pretty comprehensive Acrobat SDK. Links to it >can be found at http://partners.adobe.com/asn/developer/sdks.html. I haven't >had a good excuse to do it myself, but my impression is that if tighter >integration is required, it could be done using these tools. There is a >viewer component that can be pulled up inside another application. Last time I used the Acrobat SDK (1999) it provided support only building a plug-in to Acrobat Exchange (not free) - ie. adding functionality to Exchange itself -- things like specialized searching, indexing, or retrieving simple objects (including text) from the file, adding work flow, modifying Exchange's menus etc. It provided NO support for rendering per se, and, more importantly, had almost no support for modifying the (free) Reader. Whether one could use a plug-in as a vehicle for tightly bolting acrobat exchange is an interesting concept, but (in my opinion) we'd not have any chance to doing anything useful with the reader. I guess I think that integrating fop with the Adobe engines is a non starter although I wish that weren't the case. ' Best, -Ralph LaChance PS I just (very cursorily) rechecked the api and it does not seem much changed from what I used in the past. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
On Mon, 2002-07-29 at 11:40, RamanaJV wrote: > Ralph, > Your idea of "Fixing the awt renderer" is the correct one. After a > deep thought, I too came to the conclusion that instead of writing a PDF > renderer, if we can tune up the AWT renderer, it will be great. The main > problem with AWT renderer now is the heavy memory it uses. We need to find > the source of memory drain and tune it. Heavy memory use: - holds onto every page in memory - area tree holds onto fo tree - all images are also held in the area tree and image factory - in general far too much memory is used for many structures Solutions: - separate area tree from fo tree - allow pages to be saved to disk to reduce memory - improve image handling The design for this is mostly implemented in HEAD. (One day I will convince someone to help out with HEAD code) > We need to come up with the basic plan for this. Also, we have to > first look and summarize the current issues with AWT renderer and step > accordingly. > > Ramana. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Ralph, Your idea of "Fixing the awt renderer" is the correct one. After a deep thought, I too came to the conclusion that instead of writing a PDF renderer, if we can tune up the AWT renderer, it will be great. The main problem with AWT renderer now is the heavy memory it uses. We need to find the source of memory drain and tune it. We need to come up with the basic plan for this. Also, we have to first look and summarize the current issues with AWT renderer and step accordingly. Ramana. -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 3:06 PM To: [EMAIL PROTECTED] Subject: Re: [PDF Viewer] Utility request I agree with Oleg's last sentencetotally - which I translate roughly to "lets fix the awt renderer" In fact, I'd add a 3rd (or 2 1/2) user - the one who wishes to go directly from xml to a printer via fop. My colleagues here and I have inserted several changes to tweak spacings, borders, and so on over the past two years, and several other contributors have refined the awt renderer over even more. Recently, I got stumped by a problem in that java's font engine rasterizes glyphs differently depending on whether the target was the on-screen graphics context or a printer context. (see archives) - anyone who could help unsnarl that mess would be making a noteworthy contribution. At 07:59 AM 7/28/02, you wrote: >Matthew L. Avizinis wrote: > It might also be helpful to recognize that as FOP becomes more popular there >>are distinctly _two_ groups of "users" emerging. The first group has been >>using FOP from the beginning and those are the Java developers who use FOP >>to create some other end product. Recently I've noticed that there are more >>people attempting to use FOP who are simply people who want to use FOP as an >>end product (more of an FO viewer) and want it to fulfill the role of a >>product like X-Smiles (which unfortunately still falls far short of its goal >>of being a good FO viewer). > >I believe AWT previewer someday in the future will become some kind of FO >IDE and afaik even nowadays somebody in the team has something to donate. > >-- >Oleg Tkachenko >Multiconn International, Israel > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
I agree with Oleg's last sentencetotally - which I translate roughly to "lets fix the awt renderer" In fact, I'd add a 3rd (or 2 1/2) user - the one who wishes to go directly from xml to a printer via fop. My colleagues here and I have inserted several changes to tweak spacings, borders, and so on over the past two years, and several other contributors have refined the awt renderer over even more. Recently, I got stumped by a problem in that java's font engine rasterizes glyphs differently depending on whether the target was the on-screen graphics context or a printer context. (see archives) - anyone who could help unsnarl that mess would be making a noteworthy contribution. At 07:59 AM 7/28/02, you wrote: >Matthew L. Avizinis wrote: > It might also be helpful to recognize that as FOP becomes more popular there >>are distinctly _two_ groups of "users" emerging. The first group has been >>using FOP from the beginning and those are the Java developers who use FOP >>to create some other end product. Recently I've noticed that there are more >>people attempting to use FOP who are simply people who want to use FOP as an >>end product (more of an FO viewer) and want it to fulfill the role of a >>product like X-Smiles (which unfortunately still falls far short of its goal >>of being a good FO viewer). > >I believe AWT previewer someday in the future will become some kind of FO >IDE and afaik even nowadays somebody in the team has something to donate. > >-- >Oleg Tkachenko >Multiconn International, Israel > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Ramana, Two things - in Windows one cannot easily launch the viewer from Java, because there is no command line interface in the Win version of Reader, only DDE - a nuisance (at best) to use via Java. And yes, there is an Adobe-built java-based reader, but it is buggy, is NOT supported, and does not support the new features of present-day Acrobat. Beyond that, good luck writing a PDFEditorKit At 02:03 AM 7/28/02, Ramana wrote: > >Yep, this is OK. My thought was a viewer that can be > 1. Added to the panel component (or) > 2. A PDFEditorKit, as we have HTMLEditorKit. > >Acrobat reader is a outside application. If I launch it through a swing >application, it gives the splash screen etc. etc. The idea is to develop a >viewer which can be part of the swing application. > >Ramana. > > > >Rhett Aultman Wrote: > >I can't speak for others, but this has never been a problem in my time as a >user of FOP. My general FO document development process: > >1) Fiddle with FO document >2) Run through FOP, producing PDF file >3) Point my web browser at the PDF file >4) Web browser launches PDF viewer, either as a plugin or an external >process (depending on if I'm at my Windows or Solaris box) >5) I view the document, closing the external reader, if necessary >6) Go back to 1, except I click the browser's refresh button on 4. > >How much more simple could it get? If it's really that much of a nuisance, >why not write a .BAT file or other form of shell script to run FOP and then >launch a PDF reader to read the file? The process of doing so is fairly >simple and direct. I'm fairly sure that most people using FOP can follow >such a process. > > >-Original Message- >From: RamanaJV [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 26, 2002 5:24 AM >To: [EMAIL PROTECTED] >Subject: RE: [PDF Viewer] Utility request > > >After a little bit of exploration, I found that the JavaBean adobe gives is >not supported at all and the license tell it clear that it could contain >bugs. That JavaBean is not worth talking. When I search the web, I found >that all the activity is going in PDF creation, manipulation etc. etc. There >are good number of API's dealing with it. > >But, how much worth is a creator, without a viewer. In 90% of the >applications the needs come to launch the viewer to be part of the >application. No user prefers the print the PDF outside and again open the >Acrobat Reader to see it. This lessens the competitiveness of the product. >FOP beautifully caters to the creation of PDF, but a viewer is very much >worthy and I'm sure the FOP with a viewer definitely strikes. > >Excuse me, If I'm more user conscious... > >Ramana. > > >-Original Message- >From: Ralph LaChance [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 26, 2002 2:46 PM >To: [EMAIL PROTECTED] >Subject: Re: [PDF Viewer] Utility request > > >At 03:43 AM 7/26/02, you wrote: > >Anyone contacted Adobe to see if they wanna opensource it? > >Two years ago I contacted them to explore source licensing to my >client -- without support -- for usage in a single product and they >couldn't say no fast enough ;-) > >Later I got a back channel email from one of the developers >that mentioned something (I'm not quoting here) about company >loyalties to m$ which made them unwilling to play in the java space. > > > > ' Best, > -Ralph LaChance > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Rhett Aultman wrote: <-Start-> Yes, it's called Acrobat Reader. What's being requested is something a little more tightly integrated to FOP. <-End-> RamanaJV wrote: <-Start-> Acrobat reader is a outside application. If I launch it through a swing application, it gives the splash screen etc. etc. The idea is to develop a viewer which can be part of the swing application. <-End-> If it helps any, Adobe has a pretty comprehensive Acrobat SDK. Links to it can be found at http://partners.adobe.com/asn/developer/sdks.html. I haven't had a good excuse to do it myself, but my impression is that if tighter integration is required, it could be done using these tools. There is a viewer component that can be pulled up inside another application. If the splash screen is a big issue, I think it can be turned off in the application settings. I don't have Acrobat Reader installed locally, but (full) Acrobat has (and I think the Reader does also), a setting at the Edit / Preferences / Options screen that controls the splash screen at startup. Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 <> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Yes, it's called Acrobat Reader. What's being requested is something a little more
tightly integrated to FOP.
BTW, I think it's great that MacOSX creates PDF files when you opt to print to a file.
-Original Message-
From: Mark Malone [mailto:[EMAIL PROTECTED]]
Sent: Fri 7/26/2002 7:43 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [PDF Viewer] Utility request
Folks,
Excuse my ignorance but is the pdf viewer everyone is talking about
provided already by Adobe on a huge number of platforms and called
acrobat reader? Or is it something else that is being requested?
Also, pdf file reading is built into MacOS X as is pdf generation via
native print to file output options. What am I missing?
-M
On Friday, July 26, 2002, at 05:16 AM, Ralph LaChance wrote:
> At 05:24 AM 7/26/02, Ramana wrote:
>> But, how much worth is a creator, without a viewer. In 90% of the
>> applications the needs come to launch the viewer to be part of the
>> application. No user prefers the print the PDF outside and again open
>> the
>> Acrobat Reader to see it. This lessens the competitiveness of the
>> product.
>> FOP beautifully caters to the creation of PDF, but a viewer is very
>> much
>> worthy and I'm sure the FOP with a viewer definitely strikes.
>>
>> Excuse me, If I'm more user conscious...
>
> Strong statements. I suspect there are at least one or two folks on this
> list who might consider ~them~selves quite "user conscious," too.
>
> Perhaps you'd find that toning down the rhetoric might be a tad
> helpful... ;-)
>
>
>
> ' Best,
> -Ralph LaChance
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
<>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Matthew L. Avizinis wrote: It might also be helpful to recognize that as FOP becomes more popular there > are distinctly _two_ groups of "users" emerging. The first group has been > using FOP from the beginning and those are the Java developers who use FOP > to create some other end product. Recently I've noticed that there are more > people attempting to use FOP who are simply people who want to use FOP as an > end product (more of an FO viewer) and want it to fulfill the role of a > product like X-Smiles (which unfortunately still falls far short of its goal > of being a good FO viewer). I believe AWT previewer someday in the future will become some kind of FO IDE and afaik even nowadays somebody in the team has something to donate. -- Oleg Tkachenko Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Yep, this is OK. My thought was a viewer that can be 1. Added to the panel component (or) 2. A PDFEditorKit, as we have HTMLEditorKit. Acrobat reader is a outside application. If I launch it through a swing application, it gives the splash screen etc. etc. The idea is to develop a viewer which can be part of the swing application. Ramana. Rhett Aultman Wrote: I can't speak for others, but this has never been a problem in my time as a user of FOP. My general FO document development process: 1) Fiddle with FO document 2) Run through FOP, producing PDF file 3) Point my web browser at the PDF file 4) Web browser launches PDF viewer, either as a plugin or an external process (depending on if I'm at my Windows or Solaris box) 5) I view the document, closing the external reader, if necessary 6) Go back to 1, except I click the browser's refresh button on 4. How much more simple could it get? If it's really that much of a nuisance, why not write a .BAT file or other form of shell script to run FOP and then launch a PDF reader to read the file? The process of doing so is fairly simple and direct. I'm fairly sure that most people using FOP can follow such a process. -Original Message- From: RamanaJV [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 5:24 AM To: [EMAIL PROTECTED] Subject: RE: [PDF Viewer] Utility request After a little bit of exploration, I found that the JavaBean adobe gives is not supported at all and the license tell it clear that it could contain bugs. That JavaBean is not worth talking. When I search the web, I found that all the activity is going in PDF creation, manipulation etc. etc. There are good number of API's dealing with it. But, how much worth is a creator, without a viewer. In 90% of the applications the needs come to launch the viewer to be part of the application. No user prefers the print the PDF outside and again open the Acrobat Reader to see it. This lessens the competitiveness of the product. FOP beautifully caters to the creation of PDF, but a viewer is very much worthy and I'm sure the FOP with a viewer definitely strikes. Excuse me, If I'm more user conscious... Ramana. -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 2:46 PM To: [EMAIL PROTECTED] Subject: Re: [PDF Viewer] Utility request At 03:43 AM 7/26/02, you wrote: >Anyone contacted Adobe to see if they wanna opensource it? Two years ago I contacted them to explore source licensing to my client -- without support -- for usage in a single product and they couldn't say no fast enough ;-) Later I got a back channel email from one of the developers that mentioned something (I'm not quoting here) about company loyalties to m$ which made them unwilling to play in the java space. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Ralph LaChance wrote: > At 12:46 PM 7/25/02, you wrote: > >> After seeing the OutOfMemoryError, the AWT renderer is >> causing, why >> don't thinking of providing a PDF viewer in the FOP itself. I think, this >> will be useful so much. I don't think people couldn't have ever thought >> about it, but is it diffucult to do so? >>I feel, FOP is very much useful with the PDF viewer. What do >> others say? > > > Seems to me it might be a lot simpler to fix the awt viewer... > > Also, oddly enough doing a viewer against pdf is rather tricky - > Adobe put an un-supported java-bean on their web site, but it > is buggy and hasn't been updated in 2 or so years. The only > commercial pkg (a toolset; some assembly required) I know > of probably would pose a licensing challenge (understatement) Anyone contacted Adobe to see if they wanna opensource it? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
Folks, Excuse my ignorance but is the pdf viewer everyone is talking about provided already by Adobe on a huge number of platforms and called acrobat reader? Or is it something else that is being requested? Also, pdf file reading is built into MacOS X as is pdf generation via native print to file output options. What am I missing? -M On Friday, July 26, 2002, at 05:16 AM, Ralph LaChance wrote: > At 05:24 AM 7/26/02, Ramana wrote: >> But, how much worth is a creator, without a viewer. In 90% of the >> applications the needs come to launch the viewer to be part of the >> application. No user prefers the print the PDF outside and again open >> the >> Acrobat Reader to see it. This lessens the competitiveness of the >> product. >> FOP beautifully caters to the creation of PDF, but a viewer is very >> much >> worthy and I'm sure the FOP with a viewer definitely strikes. >> >> Excuse me, If I'm more user conscious... > > Strong statements. I suspect there are at least one or two folks on this > list who might consider ~them~selves quite "user conscious," too. > > Perhaps you'd find that toning down the rhetoric might be a tad > helpful... ;-) > > > > ' Best, > -Ralph LaChance > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
At 12:46 PM 7/25/02, you wrote: > After seeing the OutOfMemoryError, the AWT renderer is causing, why >don't thinking of providing a PDF viewer in the FOP itself. I think, this >will be useful so much. I don't think people couldn't have ever thought >about it, but is it diffucult to do so? >I feel, FOP is very much useful with the PDF viewer. What do >others say? Seems to me it might be a lot simpler to fix the awt viewer... Also, oddly enough doing a viewer against pdf is rather tricky - Adobe put an un-supported java-bean on their web site, but it is buggy and hasn't been updated in 2 or so years. The only commercial pkg (a toolset; some assembly required) I know of probably would pose a licensing challenge (understatement) ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Ramana wrote: > ... why don't thinking of providing a PDF viewer in the FOP itself. Perhaps I am missing something. Is the freely available Acrobat Reader insufficient for the task? Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
I see FOP's role as being a data transformer first and foremost. We may want to consider packaging a PDF viewer with FOP, but I'd recommend against putting it *IN* FOP. -Original Message- From: RamanaJV [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PDF Viewer] Utility request Dear FOP developers, After seeing the OutOfMemoryError, the AWT renderer is causing, why don't thinking of providing a PDF viewer in the FOP itself. I think, this will be useful so much. I don't think people couldn't have ever thought about it, but is it diffucult to do so? I feel, FOP is very much useful with the PDF viewer. What do others say? Ramana. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
