This is an old revision of the document!
PDFtalk for Gemstone
Library for reading and writing PDF files in Gemstone.
The source comes in two files: PDFtalk.gs
with the runtime code and PDFtalkTesting.gs
with tests and demos. UI tools and helpers used in VisualWorks are not included, because of the server nature of Gemstone.
The library needs Seaside (and Grease) as prerequisite.
The new symbol dictionary PDFtalkLibrary
will appear in the symbol list after filein (and PDFtalkTesting
after filing in the testing file). This symbol dictionary represents the namespace Smalltalk
of the library with the Values
code and some general tools.
The namespaces from VisualWorks are implemented by symbol dictionaries in Gemstone. Therefore, the PDFtalkLibrary
contains the dictionary PDFtalk
with all PDF classes. The PDFtalk
dictionary in turn contains the Fonts
dictionary which includes the OpenType
and CFF
dictionaries.
Accessing classes in namespaces is written differently.
"in VisualWorks:" PDFtalk.Fonts.OpenType.Font "in Gemstone:" ((PDFtalk at: #Fonts) at: #OpenType) at: #Font
Note that the second expression works in VisualWorks as well.
Get started
get files
filein
resulting structure
PDF alignment
Tests and Demos
Inspect the following:
PDF runAllTests
It should show 245 passing tests without errors or failures.
The demos write the test PDFs in the $HOME directory on the Gemstone server. For demos 12, 13 and 14 you need to put the PDF spec there as well.
To quickly test if all demos are running do:
PDF runAllDemos
Extension methods
Extension methods are
Runtime considerations
There are some global variables caching objects (fonts, encodings, the type hierarchy). These caches are lazily filled when accessed first. In a runtime, you may want to reset and fill all caches before deploying, either because of limited rights of the runtime user or to eliminate startup overhead-.
After all your application code is loaded, do the following to reset and fill all caches:
PDF primeRuntime
Images
There is code to save ImageXObjects as Value (i.e. source code which will reconstruct to object).
To produce the source string for a PDF image you send it asSource
. (Or you can send asPDF asSource
to a VW Image).
This string can be evaluated in Gemstone with #evaluate and will reconstruct the ImageXObject, which can be put into a PDF page as usual.
#evaluate works when the PDFtalkLibrary
symbol dictionary is in the symbol list; otherwise you can do something like I did in PDFtalk.Tests»#_gs_evaluate: .
I did not add any helper methods for saving or reading the string to / from disk…
My preferred way is to store such resources as methods. This may or may not work with your workflow. For this, I added a helper on ImageXObject. To save a PDF image a class method of ImageXObject, you can call
anImageXObject asMethod: selectorSymbol in: protocolSymbol package: packageString
I added several example images with this to ImageXObject. You can also look at the new ImageXTests where the images are used. These methods can be transferred easily form VW to Gemstone and you get the image just by calling that method.
older ideas about porting
Preliminary thoughts about the porting approach for Gemstone.
Older thoughts and discussion about Porting PDFtalk to other Smalltalk dialects.