Re: forth on maglev rails?

helmwo@xxxxxxxxx wrote:
Well, you dont describe TeX. Some things made TeX very successful...

* First of all, the markup of text and the meta-language to define
extensions should be separated.

Yes and no. I think some simple \def\...{...}s should be available to
the user.

The user then should switch over to meta-language mode. I.e. normally,
meta-language mode is not in the same file, but like with embedded CSS in
HTML, you can embed meta-language commants such as some \defs into the
document, if you like.

* Text markup should use some simple Wiki-like ASCII characters

How about making something from RFC 1345
http://www.faqs.org/rfcs/rfc1345.html ?

That seems to try to solve other things, as well, like ASCII encoding of
different languages.

* The markup is a structural text description

This has pros an cons. Nothing against "structural", but having it a
little bit "active" like in TeX is not that bad in all cases.

This is an extensible system, add whatever extension you like. I'd just say
that the markup starts structural; extend it to active. Not the other way
round (as with TeX).

* The text markup would be mode-dependent and extensible, so that Math
mode or e.g. XML mode could work well side-by-side with a normal mode,
and extensions could add their own markup characters (and XML tags)

I even think Math mode should be an extension.

With a properly factored system, it certainly will be.

* Character encoding is UTF-8

Characters should be internally encoded in CELL-size not as CHARs. How
the input works (UTF-8/16, ...) should be a question of setup.

Maybe.

* The meta-language is mostly Forth/Factor-like (higher level data types
should be as easy to use as in Factor).

I dont think so. Forth-like OK, but not all that features of Factor. I
even think it should be very basic like -say- ANS-Forth.

The meta-language is basically a typesetting language. Syntax and semantics
should take from Forth and Factor, where appropriate. Words would deal with
complex data types, so basic ANS-Forth is not the right thing.

* The core engine contains way less actual typesetting logic than TeX,
because the meta-language is capable of doing all these low-level task.

Where does the core engine ends? The TeX-core does imho not really
have much typesetting logic (except ligatures, hyphens and paragraph
breaks ;) ). And of course this minimalism is good. But because of
this simplicity it's for example not easy to typeset shaped paragraphs
or set texts along paths (maybe each line has it's own path). You'd
have to fix Web-sources in such cases, which is not the task someone
wants to do today.

My main grief is that TeX-core is minimalistic, but does not expose things.
I.e. what I'm thinking about is that the paragraph break algorithm is
described as solver for a typesetting problem *in the meta-language*. I.e.
if you like to typeset shaped paragraphs, write a solver for that problem.
It will be more complicated than the straight-forward paragraph breaking
algorithm, or it will compromise on output quality to achieve a result.

* The output is PostScript or PDF, no need to define an own device
independent format today.

Agreed. While DVI output is not really complicated of course and could
be supported (at least for simple cases). I know a lot of workflows
that where done with DVI the last years ;)

Supporting a backend for "simple cases" can be difficult. What do you do
when DVI doesn't have a way to express your more complicated command?

Fonts are a problem, though (the fonts from the
PostScript/TrueType/OpenType universe are just linearly scalable, and
don't take into account that different font size requires different
letter shapes to look good - something only the cmr series tries to
solve).

I dont think fonts are the problem today. First of all with TTF fonts
it is possible to include versions of a specific device resolution.
The second thing is that typesetting devices today do not really need
specific fonts. They can live well with TTF/T1 or something like this
since the resolutions are very good now. The only problem stays
monitors/displays where the resolution today is very crude. But for
these it makes also no sense today to develop an own solution that
makes good bitmap fonts.

No, that's not what CMR does. CMR changes the shape of characters (ideal
ones, not bitmap ones), because readability requires that. Just try to
scale cmr5, cmr7, cmr10 and cmr17 to the same size - they all look
significantly different. cmr5 is much more readable then Times New Roman
scaled to 5pt, but it also takes a bit more space.

However, the typesetting part itself should just take fonts in OpenType or
whatever font file container is easy to use.

I work since some weeks more intensively on my Forth typesetting
routines. I do have some code to produce PDF files since years. The
actual reason for my doing is that there raised some interest on my
old typesetter written in Perl (very slow, compared) and I want to
replace this by a Forth version this year.
My typesetting routines usually do have only basic "first fit"
paragraph breaking routines (because of "Sack Flöhe" (in german) that
may happen with TeX ;) ) but they can stretch the font and adjust
character spacing (some parameters control this) which makes it
looking not that bad. What I dont have is something like math-mode in
TeX, but instead my things can typeset ancient egyptian hieroglyphs ;)
What do you think about some more real brainstorming for a typesetting
(console-)application in Forth?

I'm definitely for it. Discussion via news here, whitepapers and discussion
summaries better on the forth-ev.de Wiki. If you live close to Munich,
tomorrow evening, there's our regular monthly Forth group meeting, as well.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: Typesetting chess books
    ... When you read a chess book, do you prefer small ... the textmoves (the real game moves) to be typeset as this: ... had download my fonts and ran the demo book you could appreciate that. ... Of course not all is that simple in typesetting, e.g, you cannot cut a ...
    (rec.games.chess.misc)
  • Re: What Software to Type Math In?
    ... What is "plain text"? ... which has the relevant fonts. ... This goes completely against the typesetting mentality. ... that I can type the left version directly into LaTeX. ...
    (sci.math)
  • Re: OT: HTML mail WAS: Re: Open-Cobol
    ... As with most typesetting questions, ... Fixed-width fonts are usually better for code - as are for example ... Usenet posters' font experiments. ... There are provisions in Usenet for using character sets and encodings ...
    (comp.lang.cobol)
  • Unicode coverage of TUGs Lucida
    ... I'm considering purchasing the Lucida fonts from TUG, ... of how suitable they are for typesetting non-ISO-8859-1 ...
    (comp.text.tex)