Hi,
I work actually on a PDF framework for Pharo. My project is in progress and many things are not finalized (no documentation, not enough unit tests, etc.). But, you can produce PDF documents with metadata, multiple page formats in a same document, draw tables, write text and paragraphs, play with colors and grey levels. If you test it, thanks for your remarks and suggestions. Best regards Olivier ;-) |
Hi Olivier,
On Wed, Apr 25, 2012 at 10:15 AM, Olivier Auverlot <[hidden email]> wrote: > If you test it, thanks for your remarks and suggestions. such a framework makes a lot of sense. Could you please create a few unit tests or a small web page with examples so everyone can get a glimpse of the API rapidly? Some examples for the Common Lisp equivalent are at: www.fractalconcept.com/asp/asdataQuQhZ0XhCuWs Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
Hi Damien,
this is on my road map ;-) Some practical examples are in the Artefact-Demos category. Olivier Le 25 avr. 2012 à 10:18, Damien Cassou a écrit : > Hi Olivier, > > On Wed, Apr 25, 2012 at 10:15 AM, Olivier Auverlot > <[hidden email]> wrote: >> If you test it, thanks for your remarks and suggestions. > > such a framework makes a lot of sense. Could you please create a few > unit tests or a small web page with examples so everyone can get a > glimpse of the API rapidly? Some examples for the Common Lisp > equivalent are at: www.fractalconcept.com/asp/asdataQuQhZ0XhCuWs > > Best, > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > |
In reply to this post by Damien Cassou
We really want to generate report for Moose so we are really interested by this effort.
Stef On Apr 25, 2012, at 10:18 AM, Damien Cassou wrote: > Hi Olivier, > > On Wed, Apr 25, 2012 at 10:15 AM, Olivier Auverlot > <[hidden email]> wrote: >> If you test it, thanks for your remarks and suggestions. > > such a framework makes a lot of sense. Could you please create a few > unit tests or a small web page with examples so everyone can get a > glimpse of the API rapidly? Some examples for the Common Lisp > equivalent are at: www.fractalconcept.com/asp/asdataQuQhZ0XhCuWs > > Best, > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > |
In reply to this post by Olivier Auverlot
Hi Olivier - is your project related to Christian's? http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/Pdf-in-Smalltalk
On 25 April 2012 09:30, Olivier Auverlot <[hidden email]> wrote: Hi Damien, |
Hi Francisco,
No, it's another project. Best regards Olivier Le 25 avr. 2012 à 11:24, Francisco Garau a écrit :
|
In reply to this post by Stéphane Ducasse
For our web applications a PDF generator is a crucial part too. There
were AFAIK several attempts to build such a framework in Smalltalk (SPDF, ...) but in the end none of these became feature-rich and/or powerful. I really like the new effort. Due to the past experience I am skeptical if such a framework really makes sense but I would love to be convinced from the opposite. Powerful PDF generators such as Apache FOP (based on standardised XSL:fo) face what a feature-complete framework would need to implement (area model with relative text flow, image processing, typography including font embedding, formatting, ...). Olivier, this would be my wish list BTW and very cool! ;) For those who cannot wait I propose to use Apache FOP (http://xmlgraphics.apache.org/fop) for PDF generation. Although built with Java (slow, requires a lot of ressources, etc.) it can be used as black box (servlet) fed using XML and XSL:fo data over a Unix socket. Most of our applications are using this solution at the moment as it offers a powerful solution for professional pdf documents. Ugly but works like a charm since years here... Cheers, Chris Am 25.04.12 11:23, schrieb Stéphane Ducasse: > We really want to generate report for Moose so we are really interested by this effort. > > Stef > > On Apr 25, 2012, at 10:18 AM, Damien Cassou wrote: > >> Hi Olivier, >> >> On Wed, Apr 25, 2012 at 10:15 AM, Olivier Auverlot >> <[hidden email]> wrote: >>> If you test it, thanks for your remarks and suggestions. >> >> such a framework makes a lot of sense. Could you please create a few >> unit tests or a small web page with examples so everyone can get a >> glimpse of the API rapidly? Some examples for the Common Lisp >> equivalent are at: www.fractalconcept.com/asp/asdataQuQhZ0XhCuWs >> >> Best, >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry |
In reply to this post by Olivier Auverlot
Hi Olivier. Great have a PDF framework! I am a user of this from now :) I saw a little the code, it is very clear. And I send you some comments: * In PDFFormat>>setPortrait and >>setLandscape maybe #defaultSize should be used instead of #size to get size, because otherwise, two consecutive #setLandscape result in a portrait size.
setPortrait "Set the page in portrait orientation" self portrait: true. self size: (self defaultSize x) @ (self defaultSize y). * In DFDemos>>datatableTest fix "pdfdoc setLandscape" as "pdfdoc format setLandscape". * Extract '/Users/olivier/Desktop/' from all methods of PDFDemos in a method, so I have to modify only one, Please! ;)
Finally, thank you for share this work with us. Regards.
El 25 de abril de 2012 06:42, Olivier Auverlot <[hidden email]> escribió:
|
and you can use "transposed" for more elegantly :)
setLandscape "Set the page in landscape orientation" self portrait: false. self size: self defaultSize transposed
Regards.
|
In reply to this post by Olivier Auverlot
Hi,
if you'd like any help with fonts and images I can
assist.
Perviously I've implemented those things on top of
SPDF.
Regards, Gary
|
In reply to this post by wysseier
I've adopted the poor man's solution:
1. Output my report in HTML/CSS. 2. Use wkhtmltopdf (http://code.google.com/p/wkhtmltopdf/) to convert it to PDF. The drawback is obviously the call to OSProcess but it gets the job done. On 25/04/12 06:06, Christoph Wysseier wrote: > For our web applications a PDF generator is a crucial part too. There > were AFAIK several attempts to build such a framework in Smalltalk > (SPDF, ...) but in the end none of these became feature-rich and/or > powerful. > > I really like the new effort. Due to the past experience I am skeptical > if such a framework really makes sense but I would love to be convinced > from the opposite. Powerful PDF generators such as Apache FOP (based on > standardised XSL:fo) face what a feature-complete framework would need > to implement (area model with relative text flow, image processing, > typography including font embedding, formatting, ...). > > Olivier, this would be my wish list BTW and very cool! ;) > > For those who cannot wait I propose to use Apache FOP > (http://xmlgraphics.apache.org/fop) for PDF generation. Although built > with Java (slow, requires a lot of ressources, etc.) it can be used as > black box (servlet) fed using XML and XSL:fo data over a Unix socket. > Most of our applications are using this solution at the moment as it > offers a powerful solution for professional pdf documents. Ugly but > works like a charm since years here... > > Cheers, > Chris > > Am 25.04.12 11:23, schrieb Stéphane Ducasse: >> We really want to generate report for Moose so we are really >> interested by this effort. >> >> Stef >> >> On Apr 25, 2012, at 10:18 AM, Damien Cassou wrote: >> >>> Hi Olivier, >>> >>> On Wed, Apr 25, 2012 at 10:15 AM, Olivier Auverlot >>> <[hidden email]> wrote: >>>> If you test it, thanks for your remarks and suggestions. >>> >>> such a framework makes a lot of sense. Could you please create a few >>> unit tests or a small web page with examples so everyone can get a >>> glimpse of the API rapidly? Some examples for the Common Lisp >>> equivalent are at: www.fractalconcept.com/asp/asdataQuQhZ0XhCuWs >>> >>> Best, >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry > > > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131 |
In reply to this post by Gary Chambers-4
Hi Gary,
yes. Thanks ;-) I will add you to the team (me and you in fact)
|
In reply to this post by Gastón Dall' Oglio
Hi Gastón,
Thanks for your remarks. I need of feedback for the road map. Artefact is like a baby ;-) Best regards Olivier
|
In reply to this post by Olivier Auverlot
Hi Olivier,
I've taken a look at the state of Artefact. Don't you think it would be much less work to port Christian Haider's work to Pharo? The namespace extensions to ring should be helpful to make two-way changes from both the VW and Pharo side. Stephan Eggermont |
Administrator
|
I was thinking the same thing. The usual Smalltalk duplication of effort seems to have been taken to new heights with PDF libs ;-) I totally understand the enthusiasm, because I really want it to (although more viewing than generating)! I looked at doing the port at ESUG last year, but hit the namespace wall... Sean p.s. I was reading the Cairo website the other day and PDF is one of the "output targets". Could that be helpful here?
Cheers,
Sean |
On 02/05/12 10:53 AM, Sean P. DeNigris wrote:
> > Stephan Eggermont wrote >> >> Don't you think it would be much less work >> to port Christian Haider's work to Pharo? > > I was thinking the same thing. The usual Smalltalk duplication of effort > seems to have been taken to new heights with PDF libs ;-) I've loaded Artefact, browsed the code, tried the demos. I've not seen the code for PDF4Smalltalk, because I can't figure out how to browse it without VW. However, looking at the examples at: https://gitorious.org/pdf4smalltalk/pages/Examples I get the (possibly mistaken) impression that the two frameworks do slightly different things, but the final result is a PDF in both cases. Looking at the PDFDemos of Artefact, it's clear how text and tables can be written. However, looking at the PDF4Smalltalk examples, it looks like you have to position the text and tables in your own code. Of course, I may be completely wrong about PDF4Smalltalk, since I've not seen the full code base. |
In reply to this post by Sean P. DeNigris
> Von: [hidden email]
[mailto:pharo-project- > [hidden email]] Im Auftrag von Yanni Chiu > > On 02/05/12 10:53 AM, Sean P. DeNigris wrote: > > > > Stephan Eggermont wrote > >> > >> Don't you think it would be much less work to port Christian Haider's > >> work to Pharo? > > > > I was thinking the same thing. The usual Smalltalk duplication of > > effort seems to have been taken to new heights with PDF libs ;-) > > I've loaded Artefact, browsed the code, tried the demos. > > I've not seen the code for PDF4Smalltalk, because I can't figure out how to > browse it without VW. Unfortunately, you can't :-( > However, looking at the examples at: > https://gitorious.org/pdf4smalltalk/pages/Examples > I get the (possibly mistaken) impression that the two frameworks do slightly > different things, but the final result is a PDF in both cases. > > Looking at the PDFDemos of Artefact, it's clear how text and tables can be > written. However, looking at the PDF4Smalltalk examples, it looks like you > have to position the text and tables in your own code. Of course, I may be > completely wrong about PDF4Smalltalk, since I've not seen the full code > base. I have not looked at Artefact, but from what I read, these are different things, I guess. PDF4Smalltalk is a system library providing full access to PDF. PDF objects are regular Smalltalk objects which you can read from PDF files or create them with code and write them as PDF. The PDF basics are quite complete and robust (I use it for a few years in production now), but there are also lots of features desired :-) (TrueType fonts and bitmap images to name a few). It deals purely with PDF and does not add any higher concepts like tables and other layouting facilities - in fact not even proper classes for graphics or text... (high on my list when I find time). It is like painting on a canvas: you are completely responsible for the placement of everything. To deal with that, Bob Nemec implemented Report4PDF which uses Seaside like layouting for a report generator. It is done, works and is quite nice! See http://smalltalk-bob.blogspot.de/2012/01/pdf-report-and-law-of-demeter.h tml I'd love if someone would port this to Pharo! I would help with answering questions, but I have not time to do anything substantial in the moment... Cheers, Christian |
In reply to this post by Yanni Chiu
What are we speaking of exactly ?
Here are two different features of different level : 1) the composition : - 1a) compose a document with a given structure and a style sheet For the structure, think of section / subsection etc... For the style sheet, think of LaTeX article, book or report.sty For the composition, think of page layout (when to insert page break, compose on several columns, wrap text around figures etc...). High level composition rules for example might forbid to begin a sub-section at the bottom of a page. - 1b) compose a document from a sequence of lower level graphics (including composed paragraph). The composition rule might be very simple, just compose one item over the other, insert page break if it does not fit on page. For composed text, page break can occur at any composed line or only at a carriage return. A good example was VisualWorks Document class. 2) the fileout of the composition in pdf format - 2a) including PDF document structuring conventions (DSC) if ever they exist at Smalltalk level. - 2b) without DSC, but only low level graphics Composing the paragraph also means having all the font metrics available plus eventually all the kerning rules, plus rules for inter-word spacing (non speaking of alignment and tabulation options which should be part of paragraph spec). Which PDF library is doing what exactly ? Are the low level Graphics - entirely PDF library dependent (which would mean no preview via Smalltalk graphics), - entirely dialect dependent (using exclusively VisualPart/Wrapper/GraphicsContext or Morph/Form/Canvas) - mixed (transformation of PDF graphics into Smalltalk graphics for preview and/or translation of Smalltak graphics to PDF graphics) In the last two cases, porting VW <->Squeak/Pharo might not be immediate ;) What about composition? Nicolas 2012/5/2 Yanni Chiu <[hidden email]>: > On 02/05/12 10:53 AM, Sean P. DeNigris wrote: >> >> >> Stephan Eggermont wrote >>> >>> >>> Don't you think it would be much less work >>> to port Christian Haider's work to Pharo? >> >> >> I was thinking the same thing. The usual Smalltalk duplication of effort >> seems to have been taken to new heights with PDF libs ;-) > > > I've loaded Artefact, browsed the code, tried the demos. > > I've not seen the code for PDF4Smalltalk, because I can't figure out how to > browse it without VW. However, looking at the examples at: > https://gitorious.org/pdf4smalltalk/pages/Examples > I get the (possibly mistaken) impression that the two frameworks do slightly > different things, but the final result is a PDF in both cases. > > Looking at the PDFDemos of Artefact, it's clear how text and tables can be > written. However, looking at the PDF4Smalltalk examples, it looks like you > have to position the text and tables in your own code. Of course, I may be > completely wrong about PDF4Smalltalk, since I've not seen the full code > base. > > |
In reply to this post by Yanni Chiu
> Von: [hidden email] [mailto:pharo-project-
> [hidden email]] Im Auftrag von Nicolas Cellier > > What are we speaking of exactly ? > Here are two different features of different level : I'll answer for PDF4Smalltalk > 1) the composition : > - 1a) compose a document with a given structure and a style sheet > For the structure, think of section / subsection etc... No (use Report4PDF) > For the style sheet, think of LaTeX article, book or report.sty No > For the composition, think of page layout (when to insert page break, > compose on several columns, wrap text around figures etc...). No (use Report4PDF) > High level composition rules for example might forbid to begin a sub- > section at the bottom of a page. No (use Report4PDF) > - 1b) compose a document from a sequence of lower level graphics (including > composed paragraph). > The composition rule might be very simple, just compose one item over > the other, insert page break if it does not fit on page. No (use Report4PDF) > For composed text, page break can occur at any composed line or only at a > carriage return. No (use Report4PDF) > A good example was VisualWorks Document class. > 2) the fileout of the composition in pdf format > - 2a) including PDF document structuring conventions (DSC) if ever they exist > at Smalltalk level. Fully supported > - 2b) without DSC, but only low level graphics Fully supported > > Composing the paragraph also means having all the font metrics available > plus eventually all the kerning rules, plus rules for inter-word spacing (non > speaking of alignment and tabulation options which should be part of > paragraph spec). No, but Type-1 fonts and OpenType(PS) fonts are implemented so that this information is available. > > Which PDF library is doing what exactly ? > Are the low level Graphics > - entirely PDF library dependent (which would mean no preview via Smalltalk > graphics), Yes > - entirely dialect dependent (using exclusively > VisualPart/Wrapper/GraphicsContext or Morph/Form/Canvas) No > - mixed (transformation of PDF graphics into Smalltalk graphics for preview > and/or translation of Smalltak graphics to PDF graphics) In the last two cases, > porting VW <->Squeak/Pharo might not be immediate ;) No, there is now viewing - just PDF objects Think of PDF4Smalltalk as a backend for graphics programs which do layout and such. With TrueType fonts and bitmap graphics, it should be easy to hook it up as GraphicsContext for VW or as Canvas(?) for Squeak/Pharo. Christian > > What about composition? > > Nicolas > > 2012/5/2 Yanni Chiu <[hidden email]>: > > On 02/05/12 10:53 AM, Sean P. DeNigris wrote: > >> > >> > >> Stephan Eggermont wrote > >>> > >>> > >>> Don't you think it would be much less work to port Christian > >>> Haider's work to Pharo? > >> > >> > >> I was thinking the same thing. The usual Smalltalk duplication of > >> effort seems to have been taken to new heights with PDF libs ;-) > > > > > > I've loaded Artefact, browsed the code, tried the demos. > > > > I've not seen the code for PDF4Smalltalk, because I can't figure out > > how to browse it without VW. However, looking at the examples at: > > https://gitorious.org/pdf4smalltalk/pages/Examples > > I get the (possibly mistaken) impression that the two frameworks do > > slightly different things, but the final result is a PDF in both cases. > > > > Looking at the PDFDemos of Artefact, it's clear how text and tables > > can be written. However, looking at the PDF4Smalltalk examples, it > > looks like you have to position the text and tables in your own code. > > Of course, I may be completely wrong about PDF4Smalltalk, since I've > > not seen the full code base. > > > > > > |
2012/5/2 Christian Haider <[hidden email]>:
>> Von: [hidden email] [mailto:pharo-project- >> [hidden email]] Im Auftrag von Nicolas Cellier >> >> What are we speaking of exactly ? >> Here are two different features of different level : > > I'll answer for PDF4Smalltalk > >> 1) the composition : >> - 1a) compose a document with a given structure and a style sheet >> For the structure, think of section / subsection etc... > No (use Report4PDF) >> For the style sheet, think of LaTeX article, book or report.sty > No >> For the composition, think of page layout (when to insert page break, >> compose on several columns, wrap text around figures etc...). > No (use Report4PDF) >> High level composition rules for example might forbid to begin a sub- >> section at the bottom of a page. > No (use Report4PDF) >> - 1b) compose a document from a sequence of lower level graphics (including >> composed paragraph). >> The composition rule might be very simple, just compose one item over >> the other, insert page break if it does not fit on page. > No (use Report4PDF) >> For composed text, page break can occur at any composed line or only at a >> carriage return. > No (use Report4PDF) >> A good example was VisualWorks Document class. >> 2) the fileout of the composition in pdf format >> - 2a) including PDF document structuring conventions (DSC) if ever they exist >> at Smalltalk level. > Fully supported >> - 2b) without DSC, but only low level graphics > Fully supported >> >> Composing the paragraph also means having all the font metrics available >> plus eventually all the kerning rules, plus rules for inter-word spacing (non >> speaking of alignment and tabulation options which should be part of >> paragraph spec). > No, but Type-1 fonts and OpenType(PS) fonts are implemented so that this information is available. >> >> Which PDF library is doing what exactly ? >> Are the low level Graphics >> - entirely PDF library dependent (which would mean no preview via Smalltalk >> graphics), > Yes >> - entirely dialect dependent (using exclusively >> VisualPart/Wrapper/GraphicsContext or Morph/Form/Canvas) > No >> - mixed (transformation of PDF graphics into Smalltalk graphics for preview >> and/or translation of Smalltak graphics to PDF graphics) In the last two cases, >> porting VW <->Squeak/Pharo might not be immediate ;) > No, there is now viewing - just PDF objects > > Think of PDF4Smalltalk as a backend for graphics programs which do layout and such. With TrueType fonts and bitmap graphics, it should be easy to hook it up as GraphicsContext for VW or as Canvas(?) for Squeak/Pharo. > > Christian > OK, thanks, I think it's clearer now for this framework. Here is how I understand it: An intermediate level library could render a VisualWorks Document into a PDF file thru a PDFGraphicsContext. The PDFGraphicsContext would use PDF4Smalltalk. As a Document is low level, there would be no DSC at this intermediate level. Technically, each font specification has to be mapped to a concrete PDF font, and each Paragraph has to be recomposed with these PDF fonts metrics, as it's already the case with the PostscriptGraphicsContext. An upper level library would compose the document from a structure and style sheet specifications, and could eventually produce DSC information thanks to PDF4Smalltalk support. With DSC, the document would be editable in 3rd party PDF editor (PDF writer ...). Report4PDF package already implements some of above features, and use PDF4Smalltalk as backend. From the blog, it looks a bit like the VisualWorks Document API, but certainly much more capable (can handle tables and all kinds of layouts). It's not yet clear if higher level structures are available. Since Report4PDF is published on Cincom public store, we can dig further... Knowing that the PostscriptGraphicsContext just streams out graphics primitives to the file, without needing any intermediate reification of Postscript objects (except fonts), what was the point of such implementation choice in PDF4Smalltalk? Nicolas >> >> What about composition? >> >> Nicolas >> >> 2012/5/2 Yanni Chiu <[hidden email]>: >> > On 02/05/12 10:53 AM, Sean P. DeNigris wrote: >> >> >> >> >> >> Stephan Eggermont wrote >> >>> >> >>> >> >>> Don't you think it would be much less work to port Christian >> >>> Haider's work to Pharo? >> >> >> >> >> >> I was thinking the same thing. The usual Smalltalk duplication of >> >> effort seems to have been taken to new heights with PDF libs ;-) >> > >> > >> > I've loaded Artefact, browsed the code, tried the demos. >> > >> > I've not seen the code for PDF4Smalltalk, because I can't figure out >> > how to browse it without VW. However, looking at the examples at: >> > https://gitorious.org/pdf4smalltalk/pages/Examples >> > I get the (possibly mistaken) impression that the two frameworks do >> > slightly different things, but the final result is a PDF in both cases. >> > >> > Looking at the PDFDemos of Artefact, it's clear how text and tables >> > can be written. However, looking at the PDF4Smalltalk examples, it >> > looks like you have to position the text and tables in your own code. >> > Of course, I may be completely wrong about PDF4Smalltalk, since I've >> > not seen the full code base. >> > >> > >> >> > > |
Free forum by Nabble | Edit this page |