On 12/15/22 6:56 AM, Andreas Gruhl wrote:
> .
> .
> .
> Thank you very much. I got it running. But (give me one finger and I'll take the whole hand) what about Ghostview?
> Did you also run into trouble when trying to build it?

I don't have ghostview but I do have gv if that will work for you. You
can find it in the same directory: https://theberrymans.com/php_kits/

Mark Berryman

On 12/15/22 02:32, Dave Froble wrote:
> On 12/14/2022 8:12 PM, Bill Gunshannon wrote:
>> On 12/14/22 19:12, Dave Froble wrote:
>>> On 12/14/2022 2:59 PM, Bill Gunshannon wrote:
>>>> On 12/14/22 14:00, Simon Clubley wrote:
>>>>> On 2022-12-14, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>>>>
>>>>>> When you're trying to sell the C?? levels on the idea of keeping
>>>>>> VMS around, it does not go well telling them that in order to use
>>>>>> it effectively you will also need to have Linux or Windows around.
>>>>>>
>>>>>
>>>>> That doesn't make much sense. z/OS has PC-based development tools,
>>>>
>>>> VMS isn't zOS.  Most CEOs and CIOs have heard of zOS and IBM can the
>>>> same be said for VMS and VSI?
>>>>
>>>>> and many network or embedded devices require a web browser running
>>>>> elsewhere for management interface purposes.
>>>>>
>>>>> VMS should be regarded much more like an embedded device than it is
>>>>> at the moment when it comes to managing it, if you want it to survive
>>>>> in today's world.
>>>>>
>>>>> C?? levels don't have a problem with management of devices from a PC.
>>>>> In fact, it's a well-known and comfortable concept for them.
>>>>
>>>> No, but I imagine a lot of them do have a problem with that red-headed
>>>> step child called VMS and will use any excuse they can find to get rid
>>>> of it.
>>>
>>> Why?
>>>
>>> Why do you call it names?
>>
>> Not much on English idiom, are we.
>>
>>>
>>> Why would most people want to get rid of something that is doing it's
>>> job, and
>>> doing it well?  Do you think they all have a death wish?
>>
>> One reason would be because they went to a conference, told
>> their peers what they were running, and got laughed at.  And,
>> yes, it does happen.
>>
>>>
>>> Most VMs systems that exist today exist because nothing could replace
>>> them.
>>> Got to wonder how many other systems can make that claim.
>>
>> That is just plain ridiculous.  I expect most VMS systems continue to
>> exist today because of momentum, nothing more.  There is nothing that
>> is being done on VMS that could not be done on another system.
>
> Ok.  Run VAX Basic on any other system.  For that matter, run Macro-32
> on any other system.

I knew that was coming. And that is the part that is ridiculous.
Running VAX BASIC or Macro-32 are not business tasks that anyone
actually need to do. Accounting, Sales, Inventory. Those are the
tasks that businesses need and they don't need VAX BASIC or Macro-32
to do them.

>
> If one has apps that run only on VMS then ...

One needs to move into the current century because like it or not,
the IT world has moved on.

>
> Yeah, anything can be re-implemented, but that costs, costs much more
> than some will admit.  To what purpose?  What's the business sense?

Survival.

bill

On 12/15/2022 8:50 AM, Andreas Gruhl wrote:
> Arne Vajhøj schrieb am Dienstag, 13. Dezember 2022 um 02:22:04 UTC+1:
>> If one could live with very old HTML standards, then
>> the easiest graphical browser to get to build would
>> probably be VMS Mosaic. It builds with VMS C and I would
>> expect it to build on (currently: for) VMS x86-64.
>>
>> But it is 25 years old - older than VMS NetScape. There must
>> be a lot of missing features in 2022.
>
> You are right. It only took 5 hours to get Mosaic working on X86.
> But though it is 'only' 18 years old it is missing some features we
> would need - and the character rendering is very zigzaggy.
> I will try to get a hold on newer browser sources.

That was what I expected. George Cook did a damn good job
maintaining VMS Mosaic for many years. But age shows.

Any chance that you could make your changes to make
it build and run on VMS x86-64 available for the public?

It is very old, but until NS or FF are available then
it is what is available. And even though I do not see
much professional usage, then it could be relevant
for hobbyists.

Arne

On 12/15/2022 9:43 AM, Andreas Gruhl wrote:
> Joukj schrieb am Mittwoch, 14. Dezember 2022 um 08:54:04 UTC+1:
>> Andreas Gruhl wrote:
>>> Joukj schrieb am Dienstag, 13. Dezember 2022 um 12:47:42 UTC+1:
>>>> Andreas Gruhl wrote:
>>>>> Arne Vajhøj schrieb am Dienstag, 13. Dezember 2022 um 02:22:04 UTC+1:
>>>>>> But it is 25 years old - older than VMS NetScape. There must
>>>>>> be a lot of missing features in 2022.
>>>>> Well, we could live with very old standards. We need no fancy stuff at all.
>>>>> If we just could find the source for one of the last browser versions compiled for Itanium we would dive into it and see what's coming out on X86.
>>>>> That would be far better than having nothing at all.
>>>> Some info is at (I did not test the compilation) at
>>>>
>>>> https://openvms-opensource.blogspot.com/2019/03/secure-web-browser-source.html
>>>>
>>>> From the same location as the CSWB sources I could download in the past
>>>> the sources of the firefox port for itanium.
>>>
>>> Thank you for the link. I missed it. I have some difficulties in accessing the sources but we will give it further tries.

>> All the sources are on "old" sites of HP. So i'm not sure if they are
>> present there. Anyway I have copies, but I have no idea if we can
>> distribute them.

> Your assumption seems true. None of the links that I found is still alive.
> Would be great, if you could help me.

It should be possible to get it.

HP distributed the binary. The source code is under MPL.
MPL require anyone providing a binary also providing
the source.

So HPE cannot say no.

But finding someone in HPE that understands MPL, knows where the
source is and has authority to make it available may not be easy.

But maybe someone saved it somewhere.

And then you need to get it working. And it is a larger code
base than Mosaic.

Arne

On 12/15/2022 2:34 AM, Dave Froble wrote:
> On 12/14/2022 7:29 PM, Arne Vajhøj wrote:
>> On 12/14/2022 7:18 PM, Dave Froble wrote:
>>> On 12/14/2022 2:44 PM, Jan-Erik Söderholm wrote:
>>>> Now I do not understand what you are talkning about. No one is
>>>> saying that
>>>> the client systems should "do all that the app system(s) do".
>>>
>>> If someone says "we want to be a 100% WEENDOZE shop", that's pretty
>>> much what
>>> they are saying.
>>
>> A long time ago then the difference between desktop Windows and
>> server Windows was indeed small and using both sort of made it
>> easier for IT to manage.
>>
>> But today the difference between desktop/laptops running
>> Windows 10/11 and Windows server 2016/2019/2022 in either
>> VM's under VMWare ESXi or Hyper-V or in Azure possible doing
>> kubernetes containers are pretty big. Skill reuse is
>> not as big as it once was.
>
> What maleware differences are there in the two you mention?

Traditional viruses is not really a thing any longer.

I would say that the client side Windows peoples
biggest security problem is to prevent the users from
clicking on suspect links or suspect attachments.
While the server side Windows people are worried about
attacks over the network utilizing vulnerabilities in
either third party or custom server applications.

Arne

On 12/15/22 19:27, Arne Vajhøj wrote:
> On 12/15/2022 9:43 AM, Andreas Gruhl wrote:
>> Joukj schrieb am Mittwoch, 14. Dezember 2022 um 08:54:04 UTC+1:
>>> Andreas Gruhl wrote:
>>>> Joukj schrieb am Dienstag, 13. Dezember 2022 um 12:47:42 UTC+1:
>>>>> Andreas Gruhl wrote:
>>>>>> Arne Vajhøj schrieb am Dienstag, 13. Dezember 2022 um 02:22:04 UTC+1:
>>>>>>> But it is 25 years old - older than VMS NetScape. There must
>>>>>>> be a lot of missing features in 2022.
>>>>>> Well, we could live with very old standards. We need no fancy
>>>>>> stuff at all.
>>>>>> If we just could find the source for one of the last browser
>>>>>> versions compiled for Itanium we would dive into it and see what's
>>>>>> coming out on X86.
>>>>>> That would be far better than having nothing at all.
>>>>> Some info is at (I did not test the compilation) at
>>>>>
>>>>> https://openvms-opensource.blogspot.com/2019/03/secure-web-browser-source.html
>>>>>
>>>>>  From the same location as the CSWB sources I could download in the
>>>>> past
>>>>> the sources of the firefox port for itanium.
>>>>
>>>> Thank you for the link. I missed it. I have some difficulties in
>>>> accessing the sources but we will give it further tries.
>
>>> All the sources are on "old" sites of HP. So i'm not sure if they are
>>> present there. Anyway I have copies, but I have no idea if we can
>>> distribute them.
>
>> Your assumption seems true. None of the links that I found is still
>> alive.
>> Would be great, if you could help me.
>
> It should be possible to get it.
>
> HP distributed the binary. The source code is under MPL.
> MPL require anyone providing a binary also providing
> the source.
>
> So HPE cannot say no.

But they can say that being as they are no longer in that
line of business they no longer have binaries or sources.

>
> But finding someone in HPE that understands MPL, knows where the
> source is and has authority to make it available may not be easy.

See my comment above. :-)

bill

On 12/15/2022 8:13 PM, Bill Gunshannon wrote:
> On 12/15/22 19:27, Arne Vajhøj wrote:
>> On 12/15/2022 9:43 AM, Andreas Gruhl wrote:
>>> Your assumption seems true. None of the links that I found is still
>>> alive.
>>> Would be great, if you could help me.
>>
>> It should be possible to get it.
>>
>> HP distributed the binary. The source code is under MPL.
>> MPL require anyone providing a binary also providing
>> the source.
>>
>> So HPE cannot say no.
>
> But they can say that being as they are no longer in that
> line of business they no longer have binaries or sources.
>
>>
>> But finding someone in HPE that understands MPL, knows where the
>> source is and has authority to make it available may not be easy.
>
> See my comment above.  :-)

I don't think that argument would fly in court.

(disclaimer: I am not a lawyer)

COMPAQ and HP took some open source software, modified it
and build it and delivered to their customers. That
process created some legal obligation due to the
license (MPL).

I do not expect legal obligations for businesses to
disappear just because they since have dropped out
of the market where the obligation was made.

Arne

Arne Vajhøj schrieb am Freitag, 16. Dezember 2022 um 01:19:09 UTC+1:
> On 12/15/2022 8:50 AM, Andreas Gruhl wrote:
> > Arne Vajhøj schrieb am Dienstag, 13. Dezember 2022 um 02:22:04 UTC+1:
> >> If one could live with very old HTML standards, then
> >> the easiest graphical browser to get to build would
> >> probably be VMS Mosaic. It builds with VMS C and I would
> >> expect it to build on (currently: for) VMS x86-64.
> >>
> >> But it is 25 years old - older than VMS NetScape. There must
> >> be a lot of missing features in 2022.
> >
> > You are right. It only took 5 hours to get Mosaic working on X86.
> > But though it is 'only' 18 years old it is missing some features we
> > would need - and the character rendering is very zigzaggy.
> > I will try to get a hold on newer browser sources.
> That was what I expected. George Cook did a damn good job
> maintaining VMS Mosaic for many years. But age shows.
>
> Any chance that you could make your changes to make
> it build and run on VMS x86-64 available for the public?

I feel it's my duty to make the changes public. Working on it.
Andreas
>
> It is very old, but until NS or FF are available then
> it is what is available. And even though I do not see
> much professional usage, then it could be relevant
> for hobbyists.
>
> Arne

Mark Berryman schrieb am Donnerstag, 15. Dezember 2022 um 20:10:24 UTC+1:
> On 12/15/22 6:56 AM, Andreas Gruhl wrote:
> > .
> > .
> > .
> > Thank you very much. I got it running. But (give me one finger and I'll take the whole hand) what about Ghostview?
> > Did you also run into trouble when trying to build it?
> I don't have ghostview but I do have gv if that will work for you. You
> can find it in the same directory: https://theberrymans.com/php_kits/
>
Thank you very much. Runs just fine.
Are you interested in my X86-Mosaic-Version?
Andreas
> Mark Berryman

On 12/16/22 10:55 AM, Andreas Gruhl wrote:
> Mark Berryman schrieb am Donnerstag, 15. Dezember 2022 um 20:10:24 UTC+1:
>> On 12/15/22 6:56 AM, Andreas Gruhl wrote:
>>> .
>>> .
>>> .
>>> Thank you very much. I got it running. But (give me one finger and I'll take the whole hand) what about Ghostview?
>>> Did you also run into trouble when trying to build it?
>> I don't have ghostview but I do have gv if that will work for you. You
>> can find it in the same directory: https://theberrymans.com/php_kits/
>>
> Thank you very much. Runs just fine.
> Are you interested in my X86-Mosaic-Version?

When I get a little time I am going to try to build the old Firefox kit
on IA64. If that works, I will try to build it for x86.

Mark Berryman

On 2022-12-16 21:13:14 +0000, Mark Berryman said:

> When I get a little time I am going to try to build the old Firefox kit
> on IA64. If that works, I will try to build it for x86.

For those following along at home, Firefox source code for the V2.0-18
OpenVMS I64 port, and porting-related docs:

https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html

FWB_I64_V2018SOURCE.SFX_I64EXE is available there.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/16/2022 5:49 PM, Stephen Hoffman wrote:
> On 2022-12-16 21:13:14 +0000, Mark Berryman said:
>> When I get a little time I am going to try to build the old Firefox
>> kit on IA64.  If that works, I will try to build it for x86.
>
> For those following along at home, Firefox source code for the V2.0-18
> OpenVMS I64 port, and porting-related docs:
>
> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>
> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.

It links to ftp.hp.com and it seems to reject connections.

:-(

But maybe it will work later.

Anyway the page has a list of prerequisites:

<quote>
Software Prerequisites and Configuration

System Software

The following system software is required:

OpenVMS V8.2-1 or higher
HP C V7.1 or higher
HP C++ V7.2 or higher
GNV V1.6-2 or later
Perl V5.8 or later
Build GTK, OPL, LIBIDL from sources (links are provided above)
ODS-5 disk

Account Quotas

The build account should have the following quotas as a minimum:

Maxjobs: 0 Fillm: 5000 Bytlm: 20000000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 500 JTquota: 4096
Prclm: 50 DIOlm: 500 WSdef: 1000000
Prio: 4 ASTlm: 500 WSquo: 1000000
Queprio: 4 TQElm: 200 WSextent: 1000000
CPU: (none) Enqlm: 3000 Pgflquo: 7000000

Disk Space

In addition to the disk space requirements for the prerequisite
software, the following is also required:

500,000(confirm the block size) blocks for the source code area
6,841,724 (confirm the block size) blocks for a non-debug build
area and/or 10,418,680 blocks for a debug area
</quote>

The space requirements for OBJ+EXE are let us say "interesting".

Arne

On 12/16/2022 6:42 PM, Arne Vajhøj wrote:
> On 12/16/2022 5:49 PM, Stephen Hoffman wrote:
>> On 2022-12-16 21:13:14 +0000, Mark Berryman said:
>>> When I get a little time I am going to try to build the old Firefox
>>> kit on IA64.  If that works, I will try to build it for x86.
>>
>> For those following along at home, Firefox source code for the V2.0-18
>> OpenVMS I64 port, and porting-related docs:
>>
>> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>>
>> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.
>
> It links to ftp.hp.com and it seems to reject connections.
>
> :-(
>
> But maybe it will work later.

HTTP to ftp.hp.com work.

So:

http://ftp.ext.hp.com/pub/openvms/cswb/FWB_I64_V2018SOURCE.SFX_I64EXE

Arne

On Fri, 2022-12-16 at 17:49 -0500, Stephen Hoffman wrote:
> On 2022-12-16 21:13:14 +0000, Mark Berryman said:
>
> > When I get a little time I am going to try to build the old Firefox
> > kit
> > on IA64.  If that works, I will try to build it for x86.
>
> For those following along at home, Firefox source code for the V2.0-
> 18
> OpenVMS I64 port, and porting-related docs:
>
> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>  
> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.

Takes 12 hours to build! It only takes 20 mins on my mighty
threadripper. I really hope that VSI will make x86 OpenVMS AMD
compatible some day.
--
Tactical Nuclear Kittens

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Phillip Helbig
> undress to reply via Info-vax
> Sent: December 14, 2022 2:32 PM
> To: info-vax@rbnsn.com
> Cc: Phillip Helbig undress to reply <helbig@asclothestro.multivax.de>
> Subject: Re: [Info-vax] Ghostscript and HTML Browser on X86
>
> In article <tncn3a$14aq$1@gioia.aioe.org>, chris <chris-nospam@tridac.net>
> writes:
>
> > Ridiculous situation, for any modern os not to have html browser
> > support. Admin and other everyday tasks have required the use of a
> > html browser for decades now and the lack of puts vms at a serious
> > disadvantage from a systems management point of view. People still
> > think a text only interface is good enough in 2022 ?, complately
> > naive.
>
> Hear, hear.
>
> I don't need, nor want it, for admin tasks, but otherwise it would useful.
>

Kind of surprised that more folks here are not aware of the recent web
support for VSI OpenVMS admin's (X86, Integrity) via a product called WebUI.

Reference:
<https://vmssoftware.com/products/webui/>

I have it running in my lab and while there is room for improvements, it is
pretty cool to be able to point/click sysuaf, disk volumes, queues etc.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 12/16/2022 6:26 PM, Single Stage to Orbit wrote:
> On Fri, 2022-12-16 at 17:49 -0500, Stephen Hoffman wrote:

>> OpenVMS I64 port, and porting-related docs:
>>
>> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>>
>> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.
>
> Takes 12 hours to build! It only takes 20 mins on my mighty
> threadripper. I really hope that VSI will make x86 OpenVMS AMD
> compatible some day.

We are working on AMD support . . .

--

--- Rob

On 12/16/2022 6:26 PM, Single Stage to Orbit wrote:
> On Fri, 2022-12-16 at 17:49 -0500, Stephen Hoffman wrote:

>> For those following along at home, Firefox source code for the V2.0- 18
>> OpenVMS I64 port, and porting-related docs:
>>
>> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>>
>> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.
>
> Takes 12 hours to build! It only takes 20 mins on my mighty threadripper. I
> really hope that VSI will make x86 OpenVMS AMD compatible some day.

We are working on AMD support . . .

--

--- Rob

On 12/16/2022 6:26 PM, Single Stage to Orbit wrote:
> On Fri, 2022-12-16 at 17:49 -0500, Stephen Hoffman wrote:
>> On 2022-12-16 21:13:14 +0000, Mark Berryman said:
>>
>>> When I get a little time I am going to try to build the old Firefox
>>> kit
>>> on IA64.  If that works, I will try to build it for x86.
>>
>> For those following along at home, Firefox source code for the V2.0-
>> 18
>> OpenVMS I64 port, and porting-related docs:
>>
>> https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
>>
>> FWB_I64_V2018SOURCE.SFX_I64EXE is available there.
>
> Takes 12 hours to build!

But are the build scripts good? So that if one
has the pieces, the disk space and the time to wait
for the build to complete then it just works (on
Itanium)?

Arne

On Sat, 2022-12-17 at 11:27 -0500, Robert A. Brooks wrote:
> On 12/16/2022 6:26 PM, Single Stage to Orbit wrote:
> > On Fri, 2022-12-16 at 17:49 -0500, Stephen Hoffman wrote:
>
> > > For those following along at home, Firefox source code for the
> > > V2.0- 18
> > > OpenVMS I64 port, and porting-related docs:
> > >
> > > https://web.archive.org/web/20130208121115/http://h71000.www7.hp.com/openvms/products/ips/firefox/fwb_source.html
> > >
> > >  FWB_I64_V2018SOURCE.SFX_I64EXE is available there.
> >
> > Takes 12 hours to build! It only takes 20 mins on my mighty
> > threadripper. I
> > really hope that VSI will make x86 OpenVMS AMD compatible some day.
>
> We are working on AMD support . . .

I'll look forward to that most eagerly!
--
Tactical Nuclear Kittens

On Thursday, December 15, 2022 at 8:10:24 PM UTC+1, Mark Berryman wrote:
> I don't have ghostview but I do have gv if that will work for you. You
> can find it in the same directory: https://theberrymans.com/php_kits/
> Mark Berryman

I think that ghostview was renamed to gv around the 2.7 release in 1996.
I have a gv 3.7.4 fork with a few years of fixes at https://github.com/william8000/gv
If you send me a pull request with VMS patches, I could add them.
There is also gsview for windows, which I think is completely separate.

As far as I know, ghostscript/ghostpdl is going to continue supporting PS, PDF, and PCL.
The recent gs 10 release has a new PDF parser written in C instead of PS for better performance and for cleaner implementations of PDF features that don't exist in PS, but they are not dropping support for PS.
They have a separate MuPDF project PDF, XPS, and EPUB.

The CHANGES file in xpdf 4.0.4 has an entry "Removed VMS build support (it hasn't been updated in ages)." under "3.04 (2014-may-28)".

Someone mentioned DECWindows. Isn't that just DEC's name for X11?

There are ports of VNC to VMS.
http://www.openvmshobbyist.com/forum/viewthread.php?forum_id=40&thread_id=447
https://www.ing.iac.es//~docs/external/vnc_docs/platforms.html

William

On 12/12/2022 5:33 AM, Phillip Helbig (undress to reply) wrote:
> <snip>
> Perhaps marginally related: I heard recently that GhostScript is
> dropping support for PostScript or something like that. Also, I think
> that the PostScript source is now publicly available.

In case nobody else has followed up, Ghostscript will no longer support
an older version of its PDF interpreter:

https://ghostscript.readthedocs.io/en/latest/News.html

Ghostscript's support of PostScript continues:

https://ghostscript.readthedocs.io/en/latest/Language.html

Louis

On 12/17/2022 5:21 PM, William wrote:
> Someone mentioned DECWindows. Isn't that just DEC's name for X11?

Yes.

X11Rsomething.something + CDE.

Arne

On 2022-12-16 23:42:41 +0000, Arne Vajhj said:

> It links to ftp.hp.com and it seems to reject connections.
>
> :-(

Odd. Worked here.

Anyway, here's a different path into the archives, and a different download:

https://archive.org/download/ftp.hp.com-openvms-20210211/cswb/

Here's most of the rest of the stuff from the ftp.hp.com/openvms path:

https://archive.org/download/ftp.hp.com-openvms-20210211

The AlphaServer path is around and cached, too.

--
Pure Personal Opinion | HoffmanLabs LLC

> In case nobody else has followed up, Ghostscript will no longer support
> an older version of its PDF interpreter:

ghostscript will continue to support PDF. The only change is that starting with gs 10, the PDF parser is implemented in C instead of in postscript for better performance and for cleaner support of PDF features that don't exist in postscript. Normal users should not notice any difference. The old PDF parser required non-standard hooks in the postscript interpreter to implement some PDF features. Removing the old PDF parser will allow some clean-up of the postscript parser to bring it closer to the postscript standard and to reduce its attack space.

On Saturday, December 17, 2022 at 11:40:25 PM UTC+1, Louis Krupp wrote:
> On 12/12/2022 5:33 AM, Phillip Helbig (undress to reply) wrote:
> > <snip>
> > Perhaps marginally related: I heard recently that GhostScript is
> > dropping support for PostScript or something like that. Also, I think
> > that the PostScript source is now publicly available.
>
> In case nobody else has followed up, Ghostscript will no longer support
> an older version of its PDF interpreter:
>
> https://ghostscript.readthedocs.io/en/latest/News.html
>
> Ghostscript's support of PostScript continues:
>
> https://ghostscript.readthedocs.io/en/latest/Language.html
>
> Louis