Discussion:
LibGD ?
(too old to reply)
Jan-Erik Soderholm
2017-03-10 13:21:24 UTC
Permalink
Raw Message
Hi.

Has anyone built the LibGD image library on VMS lately?
https://github.com/libgd/libgd/releases

We use a lot of Zebra label printers. They by default support
printing text in 0, 90, 180 and 270 degree rotation. But now
we have got a request for a label that has text that is just
slightly rotated. And it is text that in some parts will change
from label to label (serial numbers and so on), so the standard
label printer command language is not enough here.

My though is to create graphical "images" of the labels on the
fly and print them. There are Zebra commands to to that. You send
the "image" as HEX or Base64 encoded bitmapped image data.

Due to the variable data, we can not create the label images
upfront and we have just a fraction of a second after we know
the data until the label should be available for the operator.

Environment is VMS (of course) and application code in Cobol
but there is no issue to call C-routines, of course.

All GD examples I have read ends up with a file in some format.
We do not need any file, but I need to get the "image" in memory
and encode it for the printer.

For the actual text printing, it seems as the GD function
gdImageStringFT() would fit the bill since it has a "rotation"
paramater.

Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.

Regards, Jan-Erik.
Eberhard Heuser
2017-03-10 14:02:09 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Hi.
Has anyone built the LibGD image library on VMS lately?
https://github.com/libgd/libgd/releases
We use a lot of Zebra label printers. They by default support
printing text in 0, 90, 180 and 270 degree rotation. But now
we have got a request for a label that has text that is just
slightly rotated. And it is text that in some parts will change
from label to label (serial numbers and so on), so the standard
label printer command language is not enough here.
My though is to create graphical "images" of the labels on the
fly and print them. There are Zebra commands to to that. You send
the "image" as HEX or Base64 encoded bitmapped image data.
Due to the variable data, we can not create the label images
upfront and we have just a fraction of a second after we know
the data until the label should be available for the operator.
Environment is VMS (of course) and application code in Cobol
but there is no issue to call C-routines, of course.
All GD examples I have read ends up with a file in some format.
We do not need any file, but I need to get the "image" in memory
and encode it for the printer.
For the actual text printing, it seems as the GD function
gdImageStringFT() would fit the bill since it has a "rotation"
paramater.
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Regards, Jan-Erik.
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
Take a look at imagemagick. There is a VMS-prot available.

eberhard
Jan-Erik Soderholm
2017-03-10 16:15:44 UTC
Permalink
Raw Message
Post by Eberhard Heuser
Post by Jan-Erik Soderholm
Hi.
Has anyone built the LibGD image library on VMS lately?
https://github.com/libgd/libgd/releases
We use a lot of Zebra label printers. They by default support
printing text in 0, 90, 180 and 270 degree rotation. But now
we have got a request for a label that has text that is just
slightly rotated. And it is text that in some parts will change
from label to label (serial numbers and so on), so the standard
label printer command language is not enough here.
My though is to create graphical "images" of the labels on the
fly and print them. There are Zebra commands to to that. You send
the "image" as HEX or Base64 encoded bitmapped image data.
Due to the variable data, we can not create the label images
upfront and we have just a fraction of a second after we know
the data until the label should be available for the operator.
Environment is VMS (of course) and application code in Cobol
but there is no issue to call C-routines, of course.
All GD examples I have read ends up with a file in some format.
We do not need any file, but I need to get the "image" in memory
and encode it for the printer.
For the actual text printing, it seems as the GD function
gdImageStringFT() would fit the bill since it has a "rotation"
paramater.
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Regards, Jan-Erik.
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
Take a look at imagemagick. There is a VMS-prot available.
eberhard
OK, I have heard about that one also. :-) I'll take a look.
Since you mention it, I guess that you know that it also
can supply the functionallity I described. So thanks!
Arne Vajhøj
2017-03-10 17:48:01 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Has anyone built the LibGD image library on VMS lately?
https://github.com/libgd/libgd/releases
Environment is VMS (of course) and application code in Cobol
but there is no issue to call C-routines, of course.
All GD examples I have read ends up with a file in some format.
We do not need any file, but I need to get the "image" in memory
and encode it for the printer.
I have not used libgd in almost twenty years.

But:

https://libgd.github.io/manuals/2.2.4/files/gd_io-h.html

seems to support what you want.
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Sorry - can't help with that.

Arne
Jan-Erik Soderholm
2017-03-10 17:56:00 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by Jan-Erik Soderholm
Has anyone built the LibGD image library on VMS lately?
https://github.com/libgd/libgd/releases
Environment is VMS (of course) and application code in Cobol
but there is no issue to call C-routines, of course.
All GD examples I have read ends up with a file in some format.
We do not need any file, but I need to get the "image" in memory
and encode it for the printer.
I have not used libgd in almost twenty years.
https://libgd.github.io/manuals/2.2.4/files/gd_io-h.html
seems to support what you want.
Ah yes. Combined with the BMP functions here:
https://libgd.github.io/manuals/2.2.4/files/gd_bmp-c.html

Yes, looks promissing.
Post by Arne Vajhøj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Sorry - can't help with that.
Arne
Joukj
2017-03-13 09:29:53 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.

I know that Mark Berryman compiled a newer one to insert in his PHP port.


regards
Jouk
Joukj
2017-03-13 12:22:18 UTC
Permalink
Raw Message
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to
make some trivial changes to make it compile (see the above website).
Note that the DCL-script in the VMS-directory is out-dated. My patch
uses descrip.mms files for mms or mmk.

regards
Jouk
Jan-Erik Soderholm
2017-03-13 13:30:26 UTC
Permalink
Raw Message
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to make
some trivial changes to make it compile (see the above website). Note that
the DCL-script in the VMS-directory is out-dated. My patch uses descrip.mms
files for mms or mmk.
regards
Jouk
Sounds good. We will need it to be callable from our own C code.

The C code will create a label design and print it to a network
connected Zebra printer. The application will probably be listening
on a MBX for a label request and our main application will post
request on that mailbox.

Actually, we do not need support for any file type, only in-memory
1-bit bitmapped black/white, and we will never create any physical
file, just read the image in-memory and create a hex (or if it base64,
don't remember) data and send it directly to the printer. I do not
know if that has any bearing in the compilation of GD or the other
4 or 5 kits that are mandatory. I do not want to download and
install anything that is not stricly needed.

And, to make things easier to setup, I prefer staticly linked
images, not any shared images if not strucly needed.

Thanks for our input and I'll keep on looking... :-)

Jan-Erik.
Joukj
2017-03-13 14:04:02 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to make
some trivial changes to make it compile (see the above website). Note that
the DCL-script in the VMS-directory is out-dated. My patch uses descrip.mms
files for mms or mmk.
regards
Jouk
Sounds good. We will need it to be callable from our own C code.
The C code will create a label design and print it to a network
connected Zebra printer. The application will probably be listening
on a MBX for a label request and our main application will post
request on that mailbox.
Actually, we do not need support for any file type, only in-memory
1-bit bitmapped black/white, and we will never create any physical
file, just read the image in-memory and create a hex (or if it base64,
don't remember) data and send it directly to the printer. I do not
know if that has any bearing in the compilation of GD or the other
4 or 5 kits that are mandatory. I do not want to download and
install anything that is not stricly needed.
Here it is that I wonder if you need GD at all. As I understand it you
will need the following steps
1) translate the input string (character-by-character) to an
1-bit-bitmap in memory. The Freetype2 package can easily do
this. (the routine in GD you mention probably does it this way)
2) rotate the resulting by any rotation angle. (it's just some
playing with rotation matrices and pixel manipulation. I wrote
this once optimized for accuracy in Fortran, but I think
ImageMagick or GD also contain this option. But probably you'll
get a more efficient routine if you program it yourself and
be able to avoid transformation from/to
Imagemagick/GD-bitmaplayout even if it is only in memory, and
have it directly in the bitmap format you can handle to send to
the Zebra.
Post by Jan-Erik Soderholm
And, to make things easier to setup, I prefer staticly linked
images, not any shared images if not strucly needed.
Thanks for our input and I'll keep on looking... :-)
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
Jan-Erik Soderholm
2017-03-13 14:13:43 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to make
some trivial changes to make it compile (see the above website). Note that
the DCL-script in the VMS-directory is out-dated. My patch uses descrip.mms
files for mms or mmk.
regards
Jouk
Sounds good. We will need it to be callable from our own C code.
The C code will create a label design and print it to a network
connected Zebra printer. The application will probably be listening
on a MBX for a label request and our main application will post
request on that mailbox.
Actually, we do not need support for any file type, only in-memory
1-bit bitmapped black/white, and we will never create any physical
file, just read the image in-memory and create a hex (or if it base64,
don't remember) data and send it directly to the printer. I do not
know if that has any bearing in the compilation of GD or the other
4 or 5 kits that are mandatory. I do not want to download and
install anything that is not stricly needed.
Here it is that I wonder if you need GD at all. As I understand it you will
need the following steps
1) translate the input string (character-by-character) to an
1-bit-bitmap in memory. The Freetype2 package can easily do
this. (the routine in GD you mention probably does it this way)
2) rotate the resulting by any rotation angle. (it's just some
this once optimized for accuracy in Fortran, but I think
ImageMagick or GD also contain this option. But probably you'll
get a more efficient routine if you program it yourself and
be able to avoid transformation from/to
Imagemagick/GD-bitmaplayout even if it is only in memory, and
have it directly in the bitmap format you can handle to send to
the Zebra.
Post by Jan-Erik Soderholm
And, to make things easier to setup, I prefer staticly linked
images, not any shared images if not strucly needed.
Thanks for our input and I'll keep on looking... :-)
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
Yes, have also thought about that. But then, I have not programmed much
on graphic routines like that, so if some package can fix it, I'm happy.
And yes, it seems as we need the Freetype2 package at least, those
are the only fonts that can print in any angle, AFAIU.

And, also AFAIU, ImageMagic has its focus more at the command line, even
if there is also a callable library. But GD is much more focused at
the callable interface, I think...

Jan-Erik.
Joukj
2017-03-14 15:24:39 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to make
some trivial changes to make it compile (see the above website). Note that
the DCL-script in the VMS-directory is out-dated. My patch uses descrip.mms
files for mms or mmk.
regards
Jouk
Sounds good. We will need it to be callable from our own C code.
The C code will create a label design and print it to a network
connected Zebra printer. The application will probably be listening
on a MBX for a label request and our main application will post
request on that mailbox.
Actually, we do not need support for any file type, only in-memory
1-bit bitmapped black/white, and we will never create any physical
file, just read the image in-memory and create a hex (or if it base64,
don't remember) data and send it directly to the printer. I do not
know if that has any bearing in the compilation of GD or the other
4 or 5 kits that are mandatory. I do not want to download and
install anything that is not stricly needed.
Here it is that I wonder if you need GD at all. As I understand it you will
need the following steps
1) translate the input string (character-by-character) to an
1-bit-bitmap in memory. The Freetype2 package can easily do
this. (the routine in GD you mention probably does it this way)
2) rotate the resulting by any rotation angle. (it's just some
this once optimized for accuracy in Fortran, but I think
ImageMagick or GD also contain this option. But probably you'll
get a more efficient routine if you program it yourself and
be able to avoid transformation from/to
Imagemagick/GD-bitmaplayout even if it is only in memory, and
have it directly in the bitmap format you can handle to send to
the Zebra.
Post by Jan-Erik Soderholm
And, to make things easier to setup, I prefer staticly linked
images, not any shared images if not strucly needed.
Thanks for our input and I'll keep on looking... :-)
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
Yes, have also thought about that. But then, I have not programmed much
on graphic routines like that, so if some package can fix it, I'm happy.
And yes, it seems as we need the Freetype2 package at least, those
are the only fonts that can print in any angle, AFAIU.
And, also AFAIU, ImageMagic has its focus more at the command line, even
if there is also a callable library. But GD is much more focused at
the callable interface, I think...
Maybe you only need freetype: You can fill any angle in FT_Set_Transform
for reference:
https://www.freetype.org/freetype2/docs/tutorial/step1.html


regards
Jouk
Jan-Erik Soderholm
2017-03-14 16:51:51 UTC
Permalink
Raw Message
Post by Joukj
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Joukj
Post by Jan-Erik Soderholm
Anyway, I'd just liked to hear if anyone have successfully
build and used this libray on VMS. Or any pointer to similar
libraries that seems to solve this request.
Some while ago I did compile it. see
http://nchrem.tnw.tudelft.nl/openvms/software2.html#GD
I only used it for the Python port I compiled myself. If I remember
correctly the port was rather straight forward.
I just tried to compile a version extracted from github. I only had to make
some trivial changes to make it compile (see the above website). Note that
the DCL-script in the VMS-directory is out-dated. My patch uses descrip.mms
files for mms or mmk.
regards
Jouk
Sounds good. We will need it to be callable from our own C code.
The C code will create a label design and print it to a network
connected Zebra printer. The application will probably be listening
on a MBX for a label request and our main application will post
request on that mailbox.
Actually, we do not need support for any file type, only in-memory
1-bit bitmapped black/white, and we will never create any physical
file, just read the image in-memory and create a hex (or if it base64,
don't remember) data and send it directly to the printer. I do not
know if that has any bearing in the compilation of GD or the other
4 or 5 kits that are mandatory. I do not want to download and
install anything that is not stricly needed.
Here it is that I wonder if you need GD at all. As I understand it you will
need the following steps
1) translate the input string (character-by-character) to an
1-bit-bitmap in memory. The Freetype2 package can easily do
this. (the routine in GD you mention probably does it this way)
2) rotate the resulting by any rotation angle. (it's just some
this once optimized for accuracy in Fortran, but I think
ImageMagick or GD also contain this option. But probably you'll
get a more efficient routine if you program it yourself and
be able to avoid transformation from/to
Imagemagick/GD-bitmaplayout even if it is only in memory, and
have it directly in the bitmap format you can handle to send to
the Zebra.
Post by Jan-Erik Soderholm
And, to make things easier to setup, I prefer staticly linked
images, not any shared images if not strucly needed.
Thanks for our input and I'll keep on looking... :-)
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
Yes, have also thought about that. But then, I have not programmed much
on graphic routines like that, so if some package can fix it, I'm happy.
And yes, it seems as we need the Freetype2 package at least, those
are the only fonts that can print in any angle, AFAIU.
And, also AFAIU, ImageMagic has its focus more at the command line, even
if there is also a callable library. But GD is much more focused at
the callable interface, I think...
Maybe you only need freetype: You can fill any angle in FT_Set_Transform
https://www.freetype.org/freetype2/docs/tutorial/step1.html
regards
Jouk
You mean to use only Freetype without GD?

Hm, it only "writes" one character at a time, right?
And you have to update the cursor position for each
character in the string, if I'm not wrong.

I'll probably look at using GD anyway... :-)

Jan-Erik.
Jan-Erik Soderholm
2017-03-15 17:46:44 UTC
Permalink
Raw Message
Post by Joukj
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
As I said before, many thanks for your replies.
I have now collected the required kits to build GD.

Just a quick one before I start...

Is there any of these parts that requies a ODS-5 file system
before beeing unpacked?

I have now the following kits:

$ d $1$dga2902:<gd>

Directory $1$DGA2902:<GD>

BZIP2-1_0_6A_VMS.ZIP;1 4055/4144 15-MAR-2017 18:29:30.54
BZIP2_DESCRIP_SRC.MMS;1 12/112 15-MAR-2017 18:29:30.48
FREETYPE2_VMSPATCH.ZIP;1 82/112 15-MAR-2017 18:29:30.83
FT271.ZIP;1 5763/5824 15-MAR-2017 18:29:30.88
JPEG-9B_VMSPATCH.ZIP;1 9/112 15-MAR-2017 18:29:31.04
JPEGSR9B.ZIP;1 2129/2240 15-MAR-2017 18:29:31.06
LIBGD-GD-2_2_4.ZIP;1 5481/5488 15-MAR-2017 18:29:31.32
LIBXPM-3_5_11_TAR.BZ2;1 867/896 15-MAR-2017 18:29:31.40
LIBXPM-3_5_11_TAR.GZ;1 1030/1120 15-MAR-2017 18:29:31.84
LIBXPM-3_5_11_VMSPATCH.ZIP;1 4/112 15-MAR-2017 18:29:31.85
LPNG1628.ZIP;1 2557/2576 15-MAR-2017 18:29:31.92
PNGLIB_1628_VMSPATCH.ZIP;1 15/112 15-MAR-2017 18:29:32.08
ZLIB1211.ZIP;1 1460/1568 15-MAR-2017 18:29:32.11
ZLIB_1211_VMSPATCH.ZIP;1 16/112 15-MAR-2017 18:29:32.20

Total of 14 files, 23480/24528 blocks.

Now, how to unpack those BZ2 or GZ kits? I guess they have the
same content, I just copied both anyway. Or, can GD be built
without that XPM support?

Jan-Erik.
Simon Clubley
2017-03-15 18:55:25 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Directory $1$DGA2902:<GD>
LIBXPM-3_5_11_TAR.BZ2;1 867/896 15-MAR-2017 18:29:31.40
LIBXPM-3_5_11_TAR.GZ;1 1030/1120 15-MAR-2017 18:29:31.84
LIBXPM-3_5_11_VMSPATCH.ZIP;1 4/112 15-MAR-2017 18:29:31.85
Now, how to unpack those BZ2 or GZ kits? I guess they have the
same content, I just copied both anyway. Or, can GD be built
without that XPM support?
You need either gunzip or bunzip2 for VMS and then a tar for VMS.
Use the decompressor to create an uncompressed .tar file and then
use tar on VMS to unpack the directory tree.

Alternatively, just move the file over to a Linux box, unpack it
there using tar and then repack the directory tree using zip.

If you have access to a Linux box, you are probably better using
the latter option since it sounds like you are new to .gz/.bz2 files.
The tar on Linux also has integrated .gz and .bz2 support so you
can use the Linux tar to directly unpack the directory tree.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-03-15 19:03:26 UTC
Permalink
Raw Message
Post by Simon Clubley
If you have access to a Linux box, you are probably better using
the latter option since it sounds like you are new to .gz/.bz2 files.
The tar on Linux also has integrated .gz and .bz2 support so you
can use the Linux tar to directly unpack the directory tree.
One more thing. The contents of the .gz and .bz2 archives are almost
certainly the same but if you move the files over to Linux and want
to be sure you can use the Linux diff command. Unlike VMS diff, the
Linux diff can compare the two directory trees after you have unpacked
them.

The Linux diff command in this case is of the form:

diff -ur directory1/ directory2/

You will probably find both archives have the same top level directory
name so you will need to rename the first archive's top level directory
after unpacking it before unpacking the second archive.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-03-15 20:32:08 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Jan-Erik Soderholm
Directory $1$DGA2902:<GD>
LIBXPM-3_5_11_TAR.BZ2;1 867/896 15-MAR-2017 18:29:31.40
LIBXPM-3_5_11_TAR.GZ;1 1030/1120 15-MAR-2017 18:29:31.84
LIBXPM-3_5_11_VMSPATCH.ZIP;1 4/112 15-MAR-2017 18:29:31.85
Now, how to unpack those BZ2 or GZ kits? I guess they have the
same content, I just copied both anyway. Or, can GD be built
without that XPM support?
You need either gunzip or bunzip2 for VMS and then a tar for VMS.
Use the decompressor to create an uncompressed .tar file and then
use tar on VMS to unpack the directory tree.
Alternatively, just move the file over to a Linux box, unpack it
there using tar and then repack the directory tree using zip.
If you have access to a Linux box, you are probably better using
the latter option since it sounds like you are new to .gz/.bz2 files.
The tar on Linux also has integrated .gz and .bz2 support so you
can use the Linux tar to directly unpack the directory tree.
Simon.
As usual I'm very greatfull for all tips! :-)

But, I do not have access to any Linux system, I have never used a
Linux system and I have no pre-retirement plans to learn Linux. :-)

Now, by narrowing down the search I found places where ZIP archives
are also available, such as: https://github.com/winlibs/libxpm.
You can press "Clone and download" and then "Download ZIP".
It is the same version so I guess the kits are the same.

The other thing is that I have absolutely no need for the X Pixmap
file format, so if GD can be built without this (or any of the
other file formats) I'm just as happy. :-)

Now, the question is if GD can be built on a ODS-2 disk...


Jan-Erik.
Paul Sture
2017-03-15 19:24:59 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Joukj
That's how it is now set-up : you get a .olb file.
This library depends on some other pacakage's .olb files
(see documention on the web-page or in the .opt files in the patch.
As I said before, many thanks for your replies.
I have now collected the required kits to build GD.
Just a quick one before I start...
Is there any of these parts that requies a ODS-5 file system
before beeing unpacked?
$ d $1$dga2902:<gd>
Directory $1$DGA2902:<GD>
BZIP2-1_0_6A_VMS.ZIP;1 4055/4144 15-MAR-2017 18:29:30.54
BZIP2_DESCRIP_SRC.MMS;1 12/112 15-MAR-2017 18:29:30.48
FREETYPE2_VMSPATCH.ZIP;1 82/112 15-MAR-2017 18:29:30.83
FT271.ZIP;1 5763/5824 15-MAR-2017 18:29:30.88
JPEG-9B_VMSPATCH.ZIP;1 9/112 15-MAR-2017 18:29:31.04
JPEGSR9B.ZIP;1 2129/2240 15-MAR-2017 18:29:31.06
LIBGD-GD-2_2_4.ZIP;1 5481/5488 15-MAR-2017 18:29:31.32
LIBXPM-3_5_11_TAR.BZ2;1 867/896 15-MAR-2017 18:29:31.40
LIBXPM-3_5_11_TAR.GZ;1 1030/1120 15-MAR-2017 18:29:31.84
LIBXPM-3_5_11_VMSPATCH.ZIP;1 4/112 15-MAR-2017 18:29:31.85
LPNG1628.ZIP;1 2557/2576 15-MAR-2017 18:29:31.92
PNGLIB_1628_VMSPATCH.ZIP;1 15/112 15-MAR-2017 18:29:32.08
ZLIB1211.ZIP;1 1460/1568 15-MAR-2017 18:29:32.11
ZLIB_1211_VMSPATCH.ZIP;1 16/112 15-MAR-2017 18:29:32.20
Total of 14 files, 23480/24528 blocks.
Now, how to unpack those BZ2 or GZ kits? I guess they have the
same content, I just copied both anyway. Or, can GD be built
without that XPM support?
GZ files can be unpacked with gunzip or 'gzip -d' (d for decompress).
GZIP is available on the Freeware 8 CD set, but given its age I'd be
looking for a more up to date version, if that exists.

IA64 images:
<http://www.decuslib.com/freeware/freewarev80/000tools/ia64_images/>

The BZ2 kits can be unpacked by bunzip/bzip2, and you already have
the kit for that listed above.

From 'man bzip2' on a *nix system:

-d --decompress
Force decompression. bzip2, bunzip2 and bzcat are really the
same program, and the decision about what actions to take is
done on the basis of which name is used. This flag overrides
that mechanism, and forces bzip2 to decompress.
--
"Almost 88 per cent of the top 75,000 websites and 47 per cent of .com
websites rely on at least one vulnerable JavaScript library."
-- The Register, 2017-03-14
Steven Schweda
2017-03-15 21:25:53 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Is there any of these parts that requies a ODS-5 file system
before beeing unpacked?
Only one way to find out. I'd assume yes. It takes some
real dedication for a developer to stick to ODS2
restrictions.
Post by Jan-Erik Soderholm
[...]
BZIP2-1_0_6A_VMS.ZIP;1 4055/4144 15-MAR-2017 18:29:30.54
BZIP2_DESCRIP_SRC.MMS;1 12/112 15-MAR-2017 18:29:30.48
[...]
That's a kit and part of a kit.
Post by Jan-Erik Soderholm
Now, how to unpack those BZ2 or GZ kits? [...]
You don't get out much, apparently.

The (whole) bzip2 1.0.6a kit on my server should be
current. The near-by gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.) VMSTAR there (4.2) should be
adequate for most purposes. All of these programs should
come with enough documentation to explain how to build and
use.

Changing the compressed archive file names to X.tar-gz or
X.tar-bz2 might save you a step when expanding and extracting.
(Upper-case, and especially on ODS2, where ".tar.gz" can't be
done.)
Post by Jan-Erik Soderholm
[...] Unlike VMS diff, the Linux diff can compare the two
directory trees [...]
You probably mean GNU diff, part of GNU Diffutils, which
can be found (for VMS) near the other stuff on my server.

http://antinode.info/dec/index.html#Software

How anyone can survive without these things is a mystery to
me.
David Froble
2017-03-15 22:06:22 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by Jan-Erik Soderholm
Is there any of these parts that requies a ODS-5 file system
before beeing unpacked?
Only one way to find out. I'd assume yes. It takes some
real dedication for a developer to stick to ODS2
restrictions.
Post by Jan-Erik Soderholm
[...]
BZIP2-1_0_6A_VMS.ZIP;1 4055/4144 15-MAR-2017 18:29:30.54
BZIP2_DESCRIP_SRC.MMS;1 12/112 15-MAR-2017 18:29:30.48
[...]
That's a kit and part of a kit.
Post by Jan-Erik Soderholm
Now, how to unpack those BZ2 or GZ kits? [...]
You don't get out much, apparently.
The (whole) bzip2 1.0.6a kit on my server should be
current. The near-by gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.) VMSTAR there (4.2) should be
adequate for most purposes. All of these programs should
come with enough documentation to explain how to build and
use.
Changing the compressed archive file names to X.tar-gz or
X.tar-bz2 might save you a step when expanding and extracting.
(Upper-case, and especially on ODS2, where ".tar.gz" can't be
done.)
Post by Jan-Erik Soderholm
[...] Unlike VMS diff, the Linux diff can compare the two
directory trees [...]
You probably mean GNU diff, part of GNU Diffutils, which
can be found (for VMS) near the other stuff on my server.
http://antinode.info/dec/index.html#Software
How anyone can survive without these things is a mystery to
me.
Guess I'm not really here ....

ODS-2 only ....

No *ux ....
Arne Vajhøj
2017-03-16 00:29:24 UTC
Permalink
Raw Message
Post by David Froble
Post by Steven Schweda
Post by Jan-Erik Soderholm
Now, how to unpack those BZ2 or GZ kits? [...]
The (whole) bzip2 1.0.6a kit on my server should be
current. The near-by gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.) VMSTAR there (4.2) should be
adequate for most purposes. All of these programs should
come with enough documentation to explain how to build and
use.
How anyone can survive without these things is a mystery to
me.
Guess I'm not really here ....
ODS-2 only ....
No *ux ....
Even if you don't use *ux there is so much *ux stuff out there.

Certain utilities are just practical to have on all platforms
to be able to unpack stuff.

zip/unzip, tar, gzip are bzip2 some of the more common that
are good to have.

And this is not anything new. It has been like that for
20-30 years.

Arne
Steven Schweda
2017-03-16 02:20:31 UTC
Permalink
Raw Message
Post by David Froble
Guess I'm not really here ....
ODS-2 only ....
No *ux ....
You might be here for some values of "here", but an
environment which is that impoverished makes many useful
things difficult, if not impossible. (GNU "diff -r", for
example. GNU is not UNIX, you know.) But, if you're happy
on your (tiny) island, who am I to complain?
Post by David Froble
[...] gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.)
Now I remember. They've GNUified the thing so much that
getting it to work on VMS looks like a real chore. I may
wait until someone complains about an actual problem with
1.5.
David Froble
2017-03-16 03:25:55 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by David Froble
Guess I'm not really here ....
ODS-2 only ....
No *ux ....
You might be here for some values of "here", but an
environment which is that impoverished makes many useful
things difficult, if not impossible. (GNU "diff -r", for
example. GNU is not UNIX, you know.) But, if you're happy
on your (tiny) island, who am I to complain?
Post by David Froble
[...] gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.)
Now I remember. They've GNUified the thing so much that
getting it to work on VMS looks like a real chore. I may
wait until someone complains about an actual problem with
1.5.
Many of the things I read about I implemented for myself many years ago. I
doubt they would match what some people have put significant time into, but,
they work for me.

Then there is my environment and what I do. Mainly R&D, just about no normal
stuff. So perhaps my needs are a bit different.

And, you know what they say about old dogs and new tricks ....

Jan-Erik Soderholm
2017-03-16 01:12:36 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by Jan-Erik Soderholm
Is there any of these parts that requies a ODS-5 file system
before beeing unpacked?
Only one way to find out. I'd assume yes. It takes some
real dedication for a developer to stick to ODS2
restrictions.
Post by Jan-Erik Soderholm
[...]
BZIP2-1_0_6A_VMS.ZIP;1 4055/4144 15-MAR-2017 18:29:30.54
BZIP2_DESCRIP_SRC.MMS;1 12/112 15-MAR-2017 18:29:30.48
[...]
That's a kit and part of a kit.
OK, right. :-) My listing had both the source kits and some "patches"
from: http://nchrem.tnw.tudelft.nl/openvms/software2.html

Anyway, I also now found some pre-built GD kits that I'll look
closer at: http://www.decuslib.com/freeware/freewarev80/gd_jfp/
Seems as an older version, but if it does the job, fine...
Post by Steven Schweda
Post by Jan-Erik Soderholm
Now, how to unpack those BZ2 or GZ kits? [...]
You don't get out much, apparently.
The (whole) bzip2 1.0.6a kit on my server should be
current. The near-by gzip 1.5 kit is near-current. (I
haven't looked at the newer versions. 1.8 seems to be
actually current these days.) VMSTAR there (4.2) should be
adequate for most purposes. All of these programs should
come with enough documentation to explain how to build and
use.
Changing the compressed archive file names to X.tar-gz or
X.tar-bz2 might save you a step when expanding and extracting.
(Upper-case, and especially on ODS2, where ".tar.gz" can't be
done.)
Post by Jan-Erik Soderholm
[...] Unlike VMS diff, the Linux diff can compare the two
directory trees [...]
You probably mean GNU diff, part of GNU Diffutils, which
can be found (for VMS) near the other stuff on my server.
http://antinode.info/dec/index.html#Software
How anyone can survive without these things is a mystery to
me.
Loading...