Porting PDFtalk to non-namespace Smalltalk dialects

Make the core PDFtalk library available to non-namespace Smalltalk dialects like Squeak, Pharo and VAST. This does not include the UI (the Snooper), which needs to be fully rewritten in another dialect (namespaced or not).

The transformation approach to porting has been successful for Gemstone, which has namespaces. Translating all names in namespaces and their references to prefixed global names has not been done yet.

Some information about the project gives more details of the organisation and structure of the project.

The project will first concentrate on Squeak. The next candidate will probably be VA Smalltalk. Ports to other dialects (transformations for other dialects) can be developed in parallel.

Therefore, a separate page exists for each dialect:

• Squeak
• VA Smalltalk
• (others to come)

The first step is to port the Values package. This is easy, since no namespaces are involved.

1. Prepare
   1. setup the VisualWorks 8.3 source image
   2. decide on target dialect version
   3. decide on output format (Chunk?)
      1. How to handle meta data (version, author, copyright, structure…)
      2. How to handle pre- and post-load actions
      3. Add some tests
2. Port Values. No namespaces.
3. Port the PDFtalk packages in order (you can skip PostScript until later)

The workflow for the dialect specific engineer is straight forward:

1. generate the source for the target dialect from VisualWorks with the defined code transformations
2. file in the source into the target dialect
3. run the tests
4. find a problem
5. fix the problem
   1. by changing code transformations
   2. by implementing missing functionality
   3. DO NOT (well only in the last resort)
      1. change the tests to make them dialect specific
      2. change the original source in VisualWorks
6. Repeat until all tests are passing

then the port should be finished.

• PostScript - PostScript Interpreter without graphics for CMaps and type1 fonts. 83 classes, 42 values, 251 tests.
• PDFtalk - Core library. 396 classes, 116 values, 288 tests and 3 namespaces.
  • PDFtalk.Fonts - Type1 fonts. 32 classes, 5 values, 25 tests.
    • PDFtalk.Fonts.OpenType - OpenType(PS) implementation. 64 classes, 19 values, 6 tests.
• UI - not to be ported

Not included yet

• RDF - RDF implementation for meta data. 37 classes, 15 values, 371 tests.
  • PDFtalk.XMP - Extensible Metadata Platform. 17 classes, 12 values, 17 tests.

All classes and globals from a namespace will be renamed with a prefix.

• PDFtalk ⇒ Pt, PDFt, …?
• PostScript ⇒ PS, …?
• PDFtalk.Fonts ⇒ PtFont, …?
• PDFtalk.Fonts.OpenType ⇒ PtOT, …?
• RDF ⇒ RDF, …?
• PDFtalk.XMP ⇒ PtXMP, …?

(based on input from Marcel Taeumel)

• avoid conflicts with existing system classes or concepts. E.g. rename #Value to #ValueObject for Squeak
• convert namespaces to class-name prefixes. E.g. rename #Page to #PtPage
• follow naming conventions. E.g. rename Dict to #Dictionary
• avoid superfluous subclasses. E.g. rename #ColorValue to #Color for Squeak; install extensions directly in #Color class
• convert occurrences of fully-qualified class names. E.g. the use of “PDFtalk.Fonts.Font” in PDF class » #primeRuntime

• avoid conflicts with existing system categories and Monticello packages. E.g. rename 'Values' to 'VW-Values' or 'ValueObjects' for Squeak
• follow naming conventions such as “no spaces”. E.g. rename 'PDFtalk Graphics Operations' to 'PDFtalk-Graphics Operations' for Squeak; Monticello package could then be just 'PDFtalk' or 'PDFtalk-Graphics' and automatically include all such prefixed class categories

• Should be no issue in PDFtalk because package/bundle path seems to be a superset of the namespaces used. E.g. PDFtalk.Fonts.CFF.Dict is in package [PDFtalk Fonts CompactFontFormat]; so a Squeak class 'PtCFFDictionary' could be in the category 'PDFtalk-Fonts-CompactFontFormat' instead of 'PDFtalk-Fonts-CFF'

• e.g. for bundle {PDFtalk} create class “PtManifest” and use its class comment or any class-side methods as storage
• maybe not only namespaces need to be mapped to class prefixes but also bundle/package (paths) need to be mapped to class names and/or prefixes to create those extra helper classes