Re: What about these?


Thomas A. Russ ha escrito:

"Juan R." <juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx> writes:

I don't know if you are being intentionally dense or are just missing
the point of a lot of this. One major difference is that you are
comparing the entire encoding and rendering part of TeX with just the
encoding part of MathML. You ignore the internals of the rendering.
When you consider everything, it isn't quite so different. But that
undercuts your argument.

When i cited MathML i was comparing it basically with the TeX language.
When i talked about rendering thechniques i was refering to TeX engine
+ TeX fonts.

TeX engine follows a metric procedure is unnecesarily complex for
80-90% of cases. Today, we can render, fractions of arbitrary nested
level, super and subscripts, matrices, determinants, generic markers,
over and underlines and other stuff WITHOUT relying on fixed size
fonts, fixed layouts, predefined fonts...

Well, so can TeX.

No cannot you are not reading (i.e. misunderstanding) i wrote.

In fact, TeX didn't rely on fixed size fonts.

True, also printing on paper do not rely on a fixed font size, but when
someone says that one of differences between HTML publishing and paper
publishing is in that HTML format does not rely on a fixed font size,
refers to static vs dinamic types of publication.

I do not understand why you insist on misunderstanding those points.
Print on paper is usually considered to be a static media still anyone
knows that you always can change a document and print it again. But
that is not called "dinamic".

It
was able (via MetaFont) to generate whatever font it needed. I think it
was also the first to include what is now know as "optical scaling" to
fonts.

There is an entire world beyond MetaFont and TeX fonts. Precisely the
tendency on TeX comunity is to avoid old TeX engine and the TeX font
model, embracing modern font technologies.

There are problems with radicals signs, arbitrary stretchy delimiters
and some others, but there is research.

But you will admit, that this is an area that TeX has solved.

In a 'simple' and 'trivial' way, yes. We could copy today TeX way to
render radicals, it is not difficult, but that obligate to predefined
knowledge of font metrics and other stuff is not very interesting for
e-publishing. Therein we are doing research. The same for strechy.

I can do that selecting a Arial, Times or Comic Sans font. I can resize
my browser, can print, can change font on the fly, can copy and paste,
do animations... Can you?

Hmmm. You must have a different version of Comic Sans than I have. My
version is missing all sorts of specialized mathematical symbols. I see
a delta, but no del. No curl, not existential or universal
quantifiers. If I want those, I have to you the Symbol font instead,
and there's really only one of them.

I would remember this when preparing an educative article for
schoolboys. No wait, the level of math needed there does ok selecting
the Comic.

I suppose going to a full Unicode font helps out a bit here, but there
aren't that many around that have the full set of characters.

Yes Unicode fonts are a BIG. No strange so many attempts to actualize
TeX to Unicode. Something last way i looked was been not achieved with
Omega and others new 'TeXs'.

So
although you in principle have a large choice of fonts, you are
required to know (as the end user, no less) a lot more about the
contents of the font, or else you end up with either missing characters
or lots of tall, skinny boxes.

It is true that the math fonts on TeX are somewhat more limited, but it
does have a nice "out of the box" feel to it.

Example, \frac{a+b}{2}

In TeX:

- Tokenize [a] [+] [b] [2]
- Compute size for each token reading metrics for the font you
previously selected
- Render for layout you previously selected, positioning each token and
group according to metric information, parameters for layout, etc.

Static. Need of a special font containing metric information: e.g. what
is the widht of a in that font. If you change the font-type or the
font-size or resize the viewport. The process would begin again.

Well, all fonts contain metric information. Even the ones that MathML
ultimately uses to do the rendering.

I try to explain again for you. I do not need a precise knowledge of
details of the font for precise positioning and layout of most of math.
This kind of approach also work for images. I can do a fraction where
denominator is an image or a html input form. Not detailed knowledge of
the interior of the box is needed for the formatting. This simplifies a
lot of the engine and also the files can be several order of magnitude
simpler that similar approaches using a TeX like way.

In CSS-Math, CanonML ...

- Parse --> [fraction [num a + b] [den 2]]

Position each box according to box model used, e.g. CSS model, FO
model...

Oddly enough, that is exactly how TeX builds up its pages. It uses a
box model and connects the boxes using stretchy glue.

Wow! True? Now understand those horizontal and vertical boxes on TeX...
:]

All those years thinking that TeX glue was for the ink :]

No need for reading metrics for a preslected font, therefore works for
any font. The computation of box size and positions is done
automatically, without need to enter metric information to the engine.

This is completely bogus.
The rendering engine for MathML needs to read the font metric
information,

What kind of metric information? Precisely main criticism to Gecko
based browsers is that MathML is implemented over a TeX-like engine
using the TeX-fonts. This is considered to be a incorrect choice.

or else

Hum!

it would have no way to know what size to make the
boxes that contain the characters.

True, one needs to know size for positioning and layout, but there is
not reason for follow TeX. How many times i may repeat this.

Again, you either have no conception
of how the rendering engine in the browser works, or you are
deliberately ignore that stage of the processing.

Since you know everithing and are to clever, please explain me next.

You want to do a new font called Russ fonts. But you wannot do a TT
font but just a collection of GIF images [*].

Then you generate gliphs and i could still render maths with that:
fractions, Tensors, matrices... Yes i need box size for each gliph, but
that is not font metric information. I use box size and if you compute
that information from font metrics OR any other method (e.g.
offset-heigh PIXEL method) is of no importance for me.

At current state we cannot render correctly hats and other
embellishments (well it is possible but with low quality), but there
are techniques for precise positioning when talking directly with the
OS. Those techniques do not use TeX rules.

If your web browser had a TeX rendering engine, then it could take the
TeX as input and achieve the same effect.

I wonder why TeX browsers miserably failed.

We no do not use fragments, no need for computing the size of a "|"
fragment (is font dependent) for obtaining how many | i would put for a
large

/
|
|
|
\

Well, does it matter if you do your computation up front or on the fly?
It's still the same computation.

Completely wrong. Absolutely no metric information enter on the engine
when rendering the delimiter. If you are delimiting a matrix with font
numbers, then _some_ metric was used by the engine for computing the
size of the body being delimited. But substitute fonts by JPEG images
of different types of cars, and then ***no** font metric information
enter on the engine. Let me repeat again, i render the matrix and the
delimiters with zero font metric information [**].

In TeX, if you were to render a 2x2 matrix of four images of cars,
delimiting it with stretchy parentheses, you would preselect a font,
the TeX engine would read font metrics for that font and next to
construct the delimiter piece by piece "\" + n "|" + "/".

Similar stuff applies to other constructs as the radical sign.

I wait do not write again about this.

[*] Imagine you want to do this because -as previously said- you mixed
drugs with wiskey

[**] There is another version under research where you need some metric
information but much less metric information that is needed in TeX
system. One advantage of this alternative is leave you using anything
as delimiter: images, arrows, forms, any Unicode character.

.

Relevant Pages

  • Re: What about these?
    ... comparing the entire encoding and rendering part of TeX with just the ... You ignore the internals of the rendering. ... was able (via MetaFont) to generate whatever font it needed. ... group according to metric information, parameters for layout, etc. ...
    (comp.lang.lisp)
  • Re: English versus German
    ... TeX was able to handle this easily before Unicode. ... I don't know of a simple way to get both accents on the same character ... I just put an acute accent over an "m" in Word, ... font from Cambria to MS Reference Sans Serif, and now, everything I ...
    (sci.lang)
  • Re: What about these?
    ... Since TeX does not correctly encodes structure of formulae it was ... explicitely rejected as model for online Maths: e.g. MathML. ... I can do that selecting a Arial, Times or Comic Sans font. ... group according to metric information, parameters for layout, etc. ...
    (comp.lang.lisp)
  • Re: English versus German
    ... The combining diacritics work better in other programs with these ... behavior is to create the character, not change the font for the rest ... I already have *for free* in TeX, ... But it only does that for precomposed characters ...
    (sci.lang)
  • Re: English versus German
    ... Your TeX, idiot. ... Then you need to update your font. ... The combining diacritics work better in other programs with these ... have that character in that font. ...
    (sci.lang)