The main parts to port is the runtime code (see packagestructure).

You need to port [Values] first. This has many extensions to base classes, the Value class and some support classes for printing Values. The Value class should be ported first.

[PDF Basic Objects] needs the ByteCharacterEncoder class methods from the [Fonts Basics] package. Other than that, the basics of PDF, up to [PDF Fonts] can be ported without {Fonts}.

Porting the tests would be good. When all tests succeed, PDF should be working fine.

Generally, I am quite opposed to adding prefixes to every class (it hurts the eyes, hinders understanding, looses the direct connection to the names in the PDF spec and is just so non-smalltalk to me), but I do see a point with some base stock classes:

• Boolean
• Number
• Integer
• String
• Date
• Dictionary
• Rectangle

maybe also:

• Stream
• Font (there are 2: Fonts.Font and PDF.Font)
• Document
• File
• Link
• Function
• Name
• Operator
• Type
• Version

I did Array…

Yes, I see the point for the first list and I will change that when I have some time.

In general, I think the strategy to move everything to lowest common denominator is not a very attractive idea.

I would imagine that porting in the following way could work:

For the foreseeable future, I will stick with VW and the VW version will be the source of my development. If ports wish to stay close to that (not necessary, since its free and anybody can do their own thing with it), it may be better to invest in a file-out goodie which could write the source for the destination dialect from VW. All adaptations could be included there:

• replace namespaces with prefixes (run in VW, all references can be reliably found)
• replace packages/bundles with whatever module system is desired (files/git/config maps etc) including changing the names
• replace VW syntax specialties - even complex rewrites would be doable with the RBRewrite tool!
• what else? (other issues will come up, but I am sure that they can be solved in this approach).

There would be special "PortingPDFFromVWToXXX" packages/modules/FileIns for each dialect. Being so specific, it can have lots of hard-coded information and assumptions in it without causing headaches. The packages would be part of the main bundles so that they could be maintained and co-developed along with the main code.

The only task of such package would be to write out the source for one dialect or even specific versions of it. The output should be complete, so that no post-processing should be necessary (apart from saving it into ones repository).

Another approach would be to use a compatibility package like Grease or Sport to level off some differences. Somehow, I don't like the idea of taking any of those. Firstly, this would be significat code bloat for the system, since PDF would use only a fraction of the "common" functionality. Secondly, the classes in both packages are not commented and I did not find much documentation.

As I see it, Grease is the compatibility layer for Seaside and Sport is the one for Bruce's projects. Both abstract out the things they need and don't try to be comprehensive (which actually would define another Smalltalk dialect). And this is good and this is how it should be.

For PDF and Fonts, I need yet other communalities. Using 10% of Grease or Sport and then still having the need for my own compatibility package for the stuff that the two others are not covering, does not make much sense to me.

If a compatibitlity package is desirable, I probably would define my own and may copy useful stuff from Grease and Sport as fits.

Porting PDF and Fonts is not a project for an afternoon. It would require some effort.

My opinions above may be all wrong. I have not ported any sizable portions of code to other dialects yet. So, if you think that I see it wrong, please educate me - if you have good arguments, I may change my mind

What do you think?

Submitted by bobn on Wed, 2012-03-07 12:56.

I currently support production systems in VW, VA and GS. For the past couple of years most of my work has been with Seaside, requiring code that runs on all three dialects. From what I can see the vast majority of Smalltalk4PDF code will port smoothly. Personally, I do find Grease useful. If the number of dialect specific extensions is small, then maintaining our own will work. But if the list starts to get large, Grease may be a better option.

I'm happy to take responsibility for the GS port.