SPDFTests no longer fail...

Bruce Badger bwbadger at gmail.com
Thu Feb 1 21:45:46 UTC 2007


Stephan,

In response to your message direct to me I have dug through the list
archive and found your messages.  Sorry I didn't pick up on them when
you posted.

The following will appear to be a series of excuses ... and they are!

The library was written to help produce PDF reports for a web app
written ~1998 using Visual Wave.  The library was then extended for
another project that needed to convert faxes (i.e. TIFF images) to
PDF.  It has since been extended for other projects and ported to
other dialects.  It's not a product and has no full time support team.

OK - that is the foundation for the excuses, now on to some specific ones:

On 30/01/07, Stephan Eggermont <stephan at stack.nl> wrote:
> but I don't know how to operate the FileList
> opened by TIFFSelfTest displayResults...

In VisualWorks the FileList is a file browser.  The display results
method opens one of these on the results directory so you can have a
look at the .results files which contain debugging information about a
decoded TIFF image.

> What I've been trying to do is add a color
> TIFF image to the pdf, that is add a color
> bitmap. I would actually prefer to add a
> Form, but SPDF is TIFF centric.

I started looking at a number of TIFF encodings early on, and it
sounds like others have taken this further.  In the end, for the
project at hand we only needed the mono CCITT Group 4 run-length stuff
to work, so that's all I made work.

> TIFFImage has a class method
> TIFFImage fromFileNamed: aString
>         ^self fromFile: (Filename named: aString)
>
> where Filename doesn't exist as a class.

Filename is a class in VisualWorks.  The idea is that this class
understands the symbolic identifiers for file - i.e. file names.
Other classes are used to access files in VisualWorks, the FileStream
subclasses in fact.  The classes supporting files in Squeak are quite
different.

More recently I have put together the Sport library with the aim of
being able to write most code to a consistent portable interface (that
of Sport) and then have different implementations of Sport for each
dialect.  Sport is a kludge, though.  What I'd really like to see the
the Smalltalk ANSI standard moved along to include file classes ...
and all the other things in Sport.  But that won't be happening for a
while, I fear.  In the short term the SPDF library should be changed
to use Sport so we have a single SPDF implementation that works with
all Smalltalk dialects, but I certainly don't have spare volunteer
time to look at that.  I could find time in my professional (i.e. paid
for) calendar, and indeed I do sometimes get paid to do things with
the SPDF library - but not often, and not lately.

> If I put an uncompressed 24-bit TIFF in blokken.tif, an invalid pdf file
> is created...

When I did the TIFF work I had to unpack the TIFF files because we
could not get them to appear in a PDF file otherwise.  These days the
PDF spec allows one to embed graphical objects.  So really, the way
the library should work is to simply embed the compressed TIFF image
in the PDF document and let the PDF reader worry about unpacking the
image as needed.  This would make the PDFs *much* smaller too.

Here endeth the excuses.  Sorry everyone, the PDF library is what it
is, warts and all. :-/

All the best,
    Bruce
-- 
Make the most of your skills - with OpenSkills
http://www.openskills.org/



More information about the Squeak-dev mailing list