SPDFTests no longer fail...

but I don't know how to operate the FileList
opened by TIFFSelfTest displayResults...
Thanks for making the changes, Koji.
I've been able to narrow the problem down.
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.
 
TIFFImage has a class method
TIFFImage fromFileNamed: aString
        ^self fromFile: (Filename named: aString)

where Filename doesn't exist as a class.

TIFFImage fromFile: aFilename
        | readStream |
        readStream := aFilename readStream.
        readStream binary.
        ^self fromByteArray: readStream contents

So I thought to add a class method
fromFileWithName: aFilename
        | readStream |
        readStream := StandardFileStream readOnlyFileNamed: aFilename.
        readStream binary.
        ^self fromByteArray: readStream contents
                       
and duplicate test13 changing the image aquisition to

        image := (TIFFImage fromFileWithName:'blokken.tif') directories first.
       
If I put an uncompressed 24-bit TIFF in blokken.tif, an invalid pdf file
is created. If I put in a uncompressed 4-bit TIFF with an odd width,
the process halts with:
Halt: No class is ready to handle tag #320.
With an even width the invalid pdf is created again. A b/w tiff has the
same problems but the 24-bit TIFF does not have the even/odd problems.

Stephan

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 <[hidden email]> 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/

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

Bruce Badger wrote:
"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."

Another option for inter-Smalltal portability is the Passport library that I
developed in order to make Chronos work on VisualWorks, Squeak and Dolphin.
It provides the class ResourcePath, which is similar in many ways to VW's
Filename class.

For more information, see my recent blog post on Passport:
http://chronos-st.blogspot.com/2007/01/filenames-and-inter-smalltalk.html

Alan,

If you are going to be at Smalltalk Solutions this year perhaps we can
talk about Smalltalk portability.  My hope is that libraries such as
Passport and Sport melt away as the ANSI standard moves to cover more
areas so every year I lobby the Cincoms and GemStones of the world to
re-engage in the ANSI process every year - but if we could harangue
them together, that would be good :-)

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

<Bruce Badger>
Alan,

If you are going to be at Smalltalk Solutions this year perhaps we can talk
about Smalltalk portability.  My hope is that libraries such as Passport and
Sport melt away as the ANSI standard moves to cover more areas so every year
I lobby the Cincoms and GemStones of the world to re-engage in the ANSI
process every year - but if we could harangue them together, that would be
good :-)
</Bruce Badger>

I'd really like to attend, but that's just not going to be possible this
year.

I'd also really like to talk with you about inter-Smalltalk portability.
Although I generally prefer VW personally, I also strongly believe that
multiple, different Smalltalk implementations (including both commercial and
open-source platforms) are necessary to the success of Smalltalk.  I also
believe that Smalltalk is not in a position where it can afford the luxury
of any significant disunity.  United we stand, divided we fall.

Standards, and avoiding unnecessary differences in APIs, or in underlying
computational models, are key components of having a unified Smalltalk
community.  So is respect for prior art.  And in that vein, I'd like to also
mention Chris Uppal's "Common Smalltalk" project:
http://commonsmalltalk.wikispaces.com/

I do wonder whether an ANSI-governed effort at Smalltalk standardization is
the right approach, though.  Although I was overall quite pleased with the
work of the ANSI X3J20 Smalltalk committee (a former co-worker of mine, Doug
Surber, was on that committee--and he was responsible for the DateAndTime
and Duration protocols, interestingly enough,) I was not at all impressed by
the response of the Smalltalk vendors/implementors to the ANSI Standard.  To
this day, VW still fails to conform to the ANSI Standard in ways for which
there is no good excuse (e.g., try evaluating "$a codePoint" in a "virgin"
VW image--and that is just one example among many--although to be fair, the
X3J20 committee did not respect prior art in some cases--and
Character>>codePoint is a case in point.)

And then there's the amount of time it takes to get a new ANSI Standard
finalized.  Perhaps a private group of "concerned citizens" could get things
done more quickly.  "If you want something done, do it yourself."

Is it possible that a small group of those with the necessary skills, time,
interest and commitment could define **and implement** a standard Smalltalk
library for most Smalltalk platforms?  Can we "just do it" in the hope that
"build it and they will come" is more than just a catchy phrase?

--Alan

> Is it possible that a small group of those with the necessary skills, time,
> interest and commitment could define **and implement** a standard Smalltalk
> library for most Smalltalk platforms?  Can we "just do it" in the hope that
> "build it and they will come" is more than just a catchy phrase?

It is not only possible, it is probably the only way it will happen.
Even if it happens as an official standards committee, it would be a
"small group of those with the necessary skills, time, interest and
commitment".  A standards committee is more likely to happen if there
is already a de facto standard.  So, do it!

-Ralph

Glorp has a similar idea called Dialect which it uses to level the  
platforms.

On Feb 1, 2007, at 10:55 PM, Alan Lovejoy wrote:

So, we (the smalltalk community) have at least half a dozen diferent
solutions to the Smalltalk portability problem.  Each solution was
built because the author saw the same need and did not see what they
felt was a suitable existing solution.

I would very much like to see the need for the OpenSkills portability
solution, Sport, to go away.  But when we move from Sport I would want
it to be a final move.  I don't want to spend my coding time moving
all my code to the latest and greatest portability stop-gap.  Sport is
fine for now so I don't need another intermediate solution.  What I
need is a widely agreed standard that will let me throw Sport away.

OK, so how do we get an agreed standard.  We all know the formal
process is long and painful, so what can we do instead?  I know, why
don't you all just use Sport? ... ah, right.  Well, lets all get
together when we can to work out how to handle the basics like files
and sockets.  Let's have a meeting every year at Smalltalk Solutions
and who knows, in 5 or ten years we may have something agreed.  We can
work out a cool process for handling contention and for managing the
evolution of the standard.

... but wait a minute, the standards bodies *already* provide a
framework for people to develop standards - do we want to re-invent
that wheel too?

The sooner we get the ANSI committee rolling again or start a new
committee under another standards body, the better.  If it takes 5
years so be it, but we need to start sometime  if we *ever* want to
see easily portable Smalltalk code.

BTW, and FWIW I think that the standardisation process should be an
on-going and not a goal-centric effort.  I think that as things are
agreed they should be released into the published standard with the
standard being released every two years or so.  In this way we can
fairly quickly get standards in place for the things which are easy
while not being shy about discussing the things which are not so easy.

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

<Bruce Badger>
...some good points snipped...
BTW, and FWIW I think that the standardisation process should be an on-going
and not a goal-centric effort.  I think that as things are agreed they
should be released into the published standard with the standard being
released every two years or so.  In this way we can fairly quickly get
standards in place for the things which are easy while not being shy about
discussing the things which are not so easy.
</Bruce Badger>

Interesting idea.  How easy would it be to actually follow an "as each
element is ready" release strategy under the auspices of ANSI?

--Alan