[fpc-pascal]Re: working with bitmaps

[Rainer Hantsch]

Hi!

On Mon, 20 Oct 2003, Marco van de Voort wrote:
| > will not work on old Linux any more (i.e. SuSE 5.2), so they are in fact
| > useless. (I like to use very old computers to give them a second life for
| > minimalistic things, but this machines are too weak for fat new Linuxes...)
| >
| > Also I am afraid that
| > a.) this new FPC classes (again) will not use this libraries but do all
| >     this data fiddleing together by themselves. :-/
| > b.) be therefore much more unstable because the self-knitted code has to
| >     be tested again, what is already finished with this C libraries.
|      (headers also need testing)
|
|   c.) keeps the dependancies down.

Possibly you are right.  But it helps nothing when dependences are kept such
low that there exists only some trivial sub-sets but nothing useful. Wouldn't
it be better to supply something basic which is working in poorest
environments before doing something high sophisticated?


| > I asked some time ago for a wrapper and got the laconic answer that I
| > would only have to do a header translation and then do this and that...
| > :-( Why is there nothing available which does at least the simpler things
| > of that?
|
| Nobody submitted one yet.

I see that, but I can't believe that! :-)

| We only have the tool that was used for the windows unit translation.

Wrong OS. I only develop for Linux.


| > Mostly required will be those functions which reading/writing images
| > from/to files and putting them somewhere unpacked into memory for further
| > manipulation, but even this is not really available.
|
| There is pasjpg, there is a libpng header, some bmp fiddling.

Great.  'pasjpg' does not even compile on Linux. And as you already said:
There is some **fiddleing**, but nothing of it is really useful.
Some strength should be made here to build/extend the graphics unit (or add
another unit, let's say "imagefile", which should allow and supply a
standardized set of procedures/functions for both: Windoze and Linux. Nothing
in OOP/CLASS style, only very basic functions which can also be used/embedded
later within/into Delphi style classes, but they must work procedural, too.

BMP and PNG are very trivial and therefore possibly supported in some
unreliable versions. But they are extremely uncommon. Most important is JPEG,
TIFF, ... in all flavours. I am sure they are not supported directly, because
there are so many minor variations and therefore it is very complicated. So
why not offer interfaces which act as wrappers to standard libjpeg.so
libtiff.so, .... instead? Most C programs interface with these libraries, so
they should be relatively standard. Isn't it? So it would save a lot of work
when a wrapper is made, instead of re-inventing not the wheel, but the
complete car.


| > Would be nice to receive some information about where I could get a unit which
| > works with FPC 1.0.4 (this one works with SuSE 5.2, too) and is NOT in Delphi
| > Style.
|
| Obtain the latest source archive of FPC, and grep on some picture formats.
| You'll have to do the retrofitting of those sources to 1.0.4 yourself, but
| that shouldn't be too hard.

I decided to develop in Pascal at CP/M times, because this gave me the
possibility to write programs without any need to do low-level things. At DOS
this continued and allowed simple graphics, too. The logical next step would
be that the same should be available on Linux, too, and there FPC is my
"TurboPascal for Linux".

Some years ago I had the hope that FPC would become a 100% replacement for
TP/BP for DOS/LINUX/..., where I could do basically the same on every
platform without any code modification. But I still see that Linux is not very
well supported in some parts, especially graphics.
Why is there still no graph-unit available which does the same as TP.GRAPH
/DOS? Is it really such complicated to make some code into the graph unit
which opens one X11-Window and paints there as a DOS program paints on a VGA
screen?
I hear the answers in advance: This will not be satisfying, this is causing
dependices, ... -- Ok, but X11 is a standard on any graphical Unix.
And there is still some option to possibly allow to choose between using X11
and some kind of svgalib for direct access to the graphics card.
And it is even better to have *something* which runs pherhaps slow and/or
does not support more than a minimalistic set of X11, than having *nothing*
at all.

I do not want to start now with low-level things to be able to do simplest
things which were absolutely no problem with TP/BP. It is hard enough to
accept that even the graph unit is not existing to me, because it does not
work on Linux, and I see that FPC goes more and more into a direction which
does not make life very easy. Often it is enough to be able to switch into
"graphics mode" and draw some trivial graphs. This was absolutely no problem
with DOS and TP/BP, but it is impossible with Linux if you do not start with
extreme lowlevel coding. -- Hope you understand what I mean.


mfg

  Ing. Rainer Hantsch

-- 
.---------------------------------------------------------------------.
|      \\|//              Ing. Rainer HANTSCH  -  Hardware + Software |
|      (o o)        Service - Support - WEB-Design und Programmierung |
|--oOOo-(_)-oOOo------------------------------------------------------|
| Ing. Rainer HANTSCH |  mail: office at hantsch.co.at                   |
| Khunngasse 21/20    |   www: http://www.hantsch.co.at               |
| A-1030 Vienna       |   tel: +43-1-79885380    fax: +43-1-798853818 |
| ** A u s t r i a ** | handy: +43-664-9194382   UID-Nr: ATU 11134002 |
'---------------------------------------------------------------------'