2012/5/2 Christian Haider <[email protected]>: >> Von: [email protected] [mailto:pharo-project- >> [email protected]] 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 <[email protected]>: >> > 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. >> > >> > >> >> > >
