Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[<tlaronde@kergis.com>]

On Sun, May 12, 2024 at 11:01:59PM -0700, Kurt H Maier via 9fans wrote:
> [...] 
> One by one we're getting rid of the third-party software -- I
> particularly look forward to the day we can finally ditch Ghostscript --
> but in the meantime these accusations of license violations are
> misinformed and have no basis in reality.

For the ghostscript thing, and for the record (noting that, in this
area, I have put my code-money where my mouth is):

I too want to get rid of Ghostscript. The path adopted is the
TeX/METAFONT way with the following:

- A PostScript interpreter can be, functionnally, divided in two
parts: 1) a general purpose language allowing computation but aimed
for images and supposed, finally, to produce primitive graphics
directives (fixed results); 2) a rasterizer to produce a matricial
image;

- TeX is a general language, aimed at text formatting,
emitting primitive graphics directives. It's the 1) part of
PostScript;

- METAFONT is a graphical language and a black/white rasterizer;
meaning there is a already 2) with the rasterizing routines of
METAFONT.

John Hobby's MetaPost is the ability to have a graphical language,
much more easy to use than PostScript, but emiting basic PostScript
directives.

=> So there are already almost all the pieces there to obtain 1+2 at
least for obtaining the same result as *roff.

What has still to be done:

- TeX has been extended because LaTeX requires now primitives that are
not in vanilla TeX. The extended TeX engine has been written: it's
Prote, in kerTeX. Prote has to be extended to allow to use the newline
as a prevision macro character so that, indeed, roff can be, like
latex, simply a predigested set of macros with a TeX/Prote engine;

- DVI has to be extended to add a primitive, present in *roff and not
in it: spline;

- TeX/Prote has to be extended to accept UTF-8 (without, in the engine
proper, handling whatever local related thing: this has to be done at
the macro set level, or as font instructions) and to handle a font as a
directory of 256 glyphes chunks (this can be compatible with existing:
the font is searched first as a directory---extension---; if not
existing, as a file---present state, equivalent to the 0 chunk);

- A DVI interpreter has then to be written using the METAFONT
rasterizing routines to produce the end result.

One important part in the above, is that with this scheme, one has not
to take a position about roff vs. tex: underneath, there will be the
TeX/Prote engine, but interpreting whatever roff macros set is given.
One could perfectly continue to write troff-wise.

As for fonts, there are still the Hershey's digitalized ones, having
not only occidental glyphes, but oriental ones. Plus all the existing
METAFONT ones. One possible extension concerning fonts, in the DVI
rendering, would be an intermediate representation, \'a la Hershey: to
convert curved primitives to linestrings, without rasterization,
allowing a quite correct last time scaling with a very low resources
impact for final rendering.

All this, I plan to do some day. But I'm at the limit of thrashing at
the moment.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                     http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma1eb78088eb726ad7013891c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription