Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mathematical Fraktur
15 views
Skip to first unread message
Dr J R Stockton
Aug 28, 2012, 8:33:32 AM8/28/12
to
P.S. Actually, since I've now found {\frak ... } in MathJax, I no
longer currently need to get an answer to the following. But it would
be nice to know the answer, nevertheless.
I wanted to transcribe into HTML, using only 7-bit characters, that
which can be found by a Google search for '"15. Ad valorem ipsius"'.
The equations directly below that reference line contain Germanic
versions of, I believe, A B C.
I proposed to use X Y Z instead, /pro tem/. But what should I use, in
7-bit HTML, to get a moderately Germanic A B C (without insisting on the
ideal).
Answers preferred, rather than debate.
--
(c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
longer currently need to get an answer to the following. But it would
be nice to know the answer, nevertheless.
I wanted to transcribe into HTML, using only 7-bit characters, that
which can be found by a Google search for '"15. Ad valorem ipsius"'.
The equations directly below that reference line contain Germanic
versions of, I believe, A B C.
I proposed to use X Y Z instead, /pro tem/. But what should I use, in
7-bit HTML, to get a moderately Germanic A B C (without insisting on the
ideal).
Answers preferred, rather than debate.
--
(c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
Jukka K. Korpela
Aug 28, 2012, 12:21:00 PM8/28/12
to
2012-08-28 15:33, Dr J R Stockton wrote:
> I wanted to transcribe into HTML, using only 7-bit characters, that
> which can be found by a Google search for '"15. Ad valorem ipsius"'.
Google Books results, containing text from a book by Euler, it seems.
> I wanted to transcribe into HTML, using only 7-bit characters, that
> which can be found by a Google search for '"15. Ad valorem ipsius"'.
> The equations directly below that reference line contain Germanic
> versions of, I believe, A B C.
terminology is confused). Such letters are nowadays rare, but they are
used in mathematics for some structures (like ideals) and functions; in
German-speaking countries, they might be more common in math.
> I proposed to use X Y Z instead, /pro tem/.
"standard" symbols across mathematical texts, you can substitute any
suitable symbols for them, salva veritate. And X, Y, X would probably be
fine, provided that they are not otherwise used. But the choice of
symbols has stylistic impact; it does not affect denotations, but it may
affects connotations and impressions. On the other hand, how many modern
readers can read Fraktur, even to the extent of distinguishing different
Fraktur letters from each other?
> But what should I use, in
> 7-bit HTML, to get a moderately Germanic A B C (without insisting on the
> ideal).
You could use normal A, B, C but suggest a Fraktur font. Something like
<font class=fraktur>A</font> with suitable CSS. The problem is that most
systems have no Fraktur fonts installed. Using an embedded font, with
CSS @font face, would appear to be feasible.
I would *not* use <i> in this context, or any HTML or CSS construct
suggesting italic, even though variables are conventionally written in
italic. The reason is that Fraktur has no italic, and attempts to make
browsers italicize Fraktur texts might be "successful", making browsers
slant Fraktur letters, causing serious nausea.
The other approach is to use U+1D504 MATHEMATICAL FRAKTUR CAPITAL A,
etc., representable in HTML as 𝔄, etc. This approach, too, would
face font problems. Font support is rather limited:
http://www.fileformat.info/info/unicode/char/1d504/fontsupport.htm
And some of the fonts listed there would have to be excluded, for wrong
implementation of the letters. There are also some omissions in the
list. This would mean something like
font-family: Cambria Math, Symbola, Asana Math, STIX Math, XITS Math,
Code2001, Everson Mono;
for the elements containing mathematical Fraktur letters. ObHTML: doing
this in HTML with <font face="..."> would be possible, but very awkward.
And you would probably want to use of the fonts (Symbola?) as
downloadable font. It would be advisable to set line-height to a fixed
value, like 1.3, since many of the mathematically oriented fonts have
very large intrinsic (default) line height.
> Answers preferred, rather than debate.
times, to make such requests.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
tlvp
Aug 29, 2012, 2:34:49 AM8/29/12
to
On Tue, 28 Aug 2012 19:21:00 +0300, Jukka K. Korpela wrote:
> On the other hand, how many modern
> readers can read Fraktur, even to the extent of distinguishing different
> Fraktur letters from each other?
Among pure mathematicians, at any rate, about as many as can distinguish
> On the other hand, how many modern
> readers can read Fraktur, even to the extent of distinguishing different
> Fraktur letters from each other?
Greek characters from one another, which is to say, pretty nearly all :-) .
Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
tlvp
Aug 29, 2012, 2:48:28 AM8/29/12
to
On Tue, 28 Aug 2012 13:33:32 +0100, Dr J R Stockton wrote:
> I wanted to transcribe into HTML, using only 7-bit characters, that
> which can be found by a Google search for '"15. Ad valorem ipsius"'.
>
> The equations directly below that reference line contain Germanic
> versions of, I believe, A B C.
As well as the two ideas Jukka posted that I wish were easier to realize,
> I wanted to transcribe into HTML, using only 7-bit characters, that
> which can be found by a Google search for '"15. Ad valorem ipsius"'.
>
> The equations directly below that reference line contain Germanic
> versions of, I believe, A B C.
viz., the @font font-embedding, and the "use their Unicode code-points as
HTML character entities and pray your visitors' browsers support that"
approaches, there's the possibility of making tiny little .PNG graphics,
one per character, and using those as in-line images (with both alt="" and
title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
Nowhere near optimal, I agree. But at least displayable as intended in
every contemporary graphical browser I can think of.
Jukka K. Korpela
Aug 29, 2012, 3:13:43 AM8/29/12
to
2012-08-29 9:34, tlvp wrote:
> On Tue, 28 Aug 2012 19:21:00 +0300, Jukka K. Korpela wrote:
>
>> On the other hand, how many modern
>> readers can read Fraktur, even to the extent of distinguishing different
>> Fraktur letters from each other?
>
> Among pure mathematicians, at any rate, about as many as can distinguish
> Greek characters from one another, which is to say, pretty nearly all :-) .
I can read normal text in Fraktur fairly fluently, and Greek is not
> On Tue, 28 Aug 2012 19:21:00 +0300, Jukka K. Korpela wrote:
>
>> On the other hand, how many modern
>> readers can read Fraktur, even to the extent of distinguishing different
>> Fraktur letters from each other?
>
> Among pure mathematicians, at any rate, about as many as can distinguish
> Greek characters from one another, which is to say, pretty nearly all :-) .
Hebrew to me, but I find Fraktur capitals hard to distinguish from each
other. Things would probably be different if I had read loads of math
texts that use them all the time.
The distinguishability, or readability, aspect is relevant to the choice
between the two approaches. If you use styled text (normal A, B, C...
with font suggestions), the user can simply tell her browser to ignore
font suggestions on web pages. Well, most people don't know how to do
that, but the author could make it easier by providing a
JavaScript-driven button that changes the font of the elements
containing the letters meant to appear in Fraktur, perhaps with some
other change (color change?) that distinguishes them from normal letters
(just in case the text contains e.g. both normal A and Fraktur-A as
symbols).
Well, you could also have a button that changes mathematical Fraktur
characters to normal (styled) characters. Needs just a little more
JavaScript code.
An interesting aspect is that Google recognizes mathematical Fraktur
letters (when represented as separate characters, like 𝔄) as
equivalent to corresponding normal letters. Yahoo and Bing seem to treat
them as special symbols, effectively ignoring them in searches.
In both approaches, you could use the title attribute, e.g.
<span class="Fraktur" title="A">𝔄</span>
or maybe with title="A (Fraktur)". Usually, the title attribute is a
poor excuse for not expressing things in content proper, but here it
could be useful, if users notice that on mouseover, a tooltip appears
for mystery characters.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jukka K. Korpela
Aug 29, 2012, 3:31:14 AM8/29/12
to
2012-08-29 9:48, tlvp wrote:
> As well as the two ideas Jukka posted that I wish were easier to realize,
> viz., the @font font-embedding, and the "use their Unicode code-points as
> HTML character entities and pray your visitors' browsers support that"
> approaches
Actually, I meant that the author could (and, really, should) use font
> As well as the two ideas Jukka posted that I wish were easier to realize,
> viz., the @font font-embedding, and the "use their Unicode code-points as
> HTML character entities and pray your visitors' browsers support that"
> approaches
embedding in both cases. Using styled text, it would suffice to embed a
font that contains just glyphs for Fraktur letters, so it can be a very
small font (selecting a *good* one could be difficult, and selecting the
*best* one even more difficult). Using mathematical Fraktur characters,
you would need to embed one of the few fonts that support these Plane 1
characters, so the font would have to be fairly large, but suitable
techniques could make it possible to embed just part of the font.
> there's the possibility of making tiny little .PNG graphics,
> one per character, and using those as in-line images (with both alt="" and
> title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
Wikipedia for example, and even in MathWorld. They often use it even for
characters that would render just fine when represented as character,
sometimes even for Latin letters with subscripts for example. I suppose
they do this either for uniformity of style or for production reasons
(the tools used favor it).
Generally, the result is typographic nightmare, especially if the same
symbols also appear on the page in formulas presented using other
technologies. Using images designed to fit the normal copy text font,
and using a copy text font that is almost universally available on
computers, it might give tolerable results.
Should you choose such an approach, it would be best to prepare largish
versions of the graphics (say, 5 times the expected copy text font size)
and scale them down with CSS, setting e.g. height: 0.8em (and not
setting width, so that the proportions will be preserved in scaling).
This would make them adapt to font size changes.
I would use alt="A" title="A (Fraktur)", because in the title, the case
of "A" makes "UC" redundant*), and the alt attribute value should be a
suitable substitute for the image, rather than a description. Well,
maybe alt="Fraktur-A" would be feasible. It really depends which of the
different uses of alt attributes in rendering or otherwise we emphasize.
*) However, for the blind, things might be different, but regarding
that, wouldn't we need title="uppercase A Fraktur"? The abbreviation
"UC" would probably be read as "you see" in speech synthesis.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Andreas Prilop
Aug 29, 2012, 12:58:12 PM8/29/12
to
On Wed, 29 Aug 2012, Jukka K. Korpela wrote:
> An interesting aspect is that Google recognizes mathematical
> Fraktur letters (when represented as separate characters,
> like 𝔄) as equivalent to corresponding normal letters.
http://www.google.co.uk/search?q=inurl:wiki-blackletter+%22x+y+z%22
> An interesting aspect is that Google recognizes mathematical
> Fraktur letters (when represented as separate characters,
> like 𝔄) as equivalent to corresponding normal letters.
http://www.google.co.uk/search?q=inurl:wiki-blackletter+%22%F0%9D%94%B5+%F0%9D%94%B6+%F0%9D%94%B7%22
give different results.
--
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/
Dr J R Stockton
Aug 29, 2012, 1:34:40 PM8/29/12
to
In comp.infosystems.www.authoring.html message <k1ir5d$bgs$1@dont-
email.me>, Tue, 28 Aug 2012 19:21:00, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-08-28 15:33, Dr J R Stockton wrote:
>
>> I wanted to transcribe into HTML, using only 7-bit characters, that
>> which can be found by a Google search for '"15. Ad valorem ipsius"'.
>
>Google Books results, containing text from a book by Euler, it seems.
XOR text by Euler from a book, which is not quite the same thing. The
printing of one version is too good for Euler's time. If you look as at
much of that as is possible, you will see footnotes of correction by
M.S. whoever he may be. Sankt Peterburg has a good scan of the original
printing; the Euler Archive has a bad scan, and has been told (recently)
of the good one. Google has not yet found it in HTML.
But I've not yet found the cited figure.
>The other approach is to use U+1D504 MATHEMATICAL FRAKTUR CAPITAL A,
>etc., representable in HTML as 𝔄, etc. This approach, too,
------------------------------- that is the forgotten answer.
>> Answers preferred, rather than debate.
>
>Oh, this is still Usenet. It's pointless, though understandable at
>times, to make such requests.
Yes, but YHBW.
I now use {\frak A} etc., surrounded by dollar signs.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
email.me>, Tue, 28 Aug 2012 19:21:00, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-08-28 15:33, Dr J R Stockton wrote:
>
>> I wanted to transcribe into HTML, using only 7-bit characters, that
>> which can be found by a Google search for '"15. Ad valorem ipsius"'.
>
>Google Books results, containing text from a book by Euler, it seems.
printing of one version is too good for Euler's time. If you look as at
much of that as is possible, you will see footnotes of correction by
M.S. whoever he may be. Sankt Peterburg has a good scan of the original
printing; the Euler Archive has a bad scan, and has been told (recently)
of the good one. Google has not yet found it in HTML.
But I've not yet found the cited figure.
>The other approach is to use U+1D504 MATHEMATICAL FRAKTUR CAPITAL A,
>etc., representable in HTML as 𝔄, etc. This approach, too,
>> Answers preferred, rather than debate.
>
>Oh, this is still Usenet. It's pointless, though understandable at
>times, to make such requests.
I now use {\frak A} etc., surrounded by dollar signs.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Dr J R Stockton
Aug 30, 2012, 4:47:50 PM8/30/12
to
In comp.infosystems.www.authoring.html message <hd85iac0m8df$.qehpcdt1n1
ms....@40tude.net>, Wed, 29 Aug 2012 02:34:49, tlvp
<mPiOsUcB...@att.net> posted:
>On Tue, 28 Aug 2012 19:21:00 +0300, Jukka K. Korpela wrote:
>
>> On the other hand, how many modern
>> readers can read Fraktur, even to the extent of distinguishing different
>> Fraktur letters from each other?
>
>Among pure mathematicians, at any rate, about as many as can distinguish
>Greek characters from one another, which is to say, pretty nearly all :-) .
I did say that the Fraktur letters were A, B, C. It's easy enough to
tell those apart, B & C are fairly easy to recognise, and the context
suggests A, B, C in that order.
Mind you, with what passed for modern print technology 250 years ago,
plus an old-style font, plus ageing of the printed copy, plus hasty
scanning, plus it being in Latin, it is in parts not easy to recognise
even the ordinary words.
ms....@40tude.net>, Wed, 29 Aug 2012 02:34:49, tlvp
<mPiOsUcB...@att.net> posted:
>On Tue, 28 Aug 2012 19:21:00 +0300, Jukka K. Korpela wrote:
>
>> On the other hand, how many modern
>> readers can read Fraktur, even to the extent of distinguishing different
>> Fraktur letters from each other?
>
>Among pure mathematicians, at any rate, about as many as can distinguish
>Greek characters from one another, which is to say, pretty nearly all :-) .
tell those apart, B & C are fairly easy to recognise, and the context
suggests A, B, C in that order.
Mind you, with what passed for modern print technology 250 years ago,
plus an old-style font, plus ageing of the printed copy, plus hasty
scanning, plus it being in Latin, it is in parts not easy to recognise
even the ordinary words.
Dr J R Stockton
Aug 30, 2012, 4:52:41 PM8/30/12
to
In comp.infosystems.www.authoring.html message <1g8w3h0kkxzbu.dlw804qnhp
t4$.d...@40tude.net>, Wed, 29 Aug 2012 02:48:28, tlvp
<mPiOsUcB...@att.net> posted:
>As well as the two ideas Jukka posted that I wish were easier to realize,
>viz., the @font font-embedding, and the "use their Unicode code-points as
>HTML character entities and pray your visitors' browsers support that"
>approaches, there's the possibility of making tiny little .PNG graphics,
>one per character, and using those as in-line images (with both alt="" and
>title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
To that one should add "and sized in ex units", in which case they will
Zoom with the ordinary text using Firefox, Zoom Text Only.
<http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3 6.20 ; WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
t4$.d...@40tude.net>, Wed, 29 Aug 2012 02:48:28, tlvp
<mPiOsUcB...@att.net> posted:
>As well as the two ideas Jukka posted that I wish were easier to realize,
>viz., the @font font-embedding, and the "use their Unicode code-points as
>HTML character entities and pray your visitors' browsers support that"
>approaches, there's the possibility of making tiny little .PNG graphics,
>one per character, and using those as in-line images (with both alt="" and
>title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
Zoom with the ordinary text using Firefox, Zoom Text Only.
<http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3 6.20 ; WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
David Stone
Aug 31, 2012, 9:00:43 AM8/31/12
to
In article <psnlCjMZ...@invalid.uk.co.demon.merlyn.invalid>,
operation of zoom function between text in em and ex units?
Dr J R Stockton <repl...@merlyn.demon.co.uk.invalid> wrote:
> In comp.infosystems.www.authoring.html message <1g8w3h0kkxzbu.dlw804qnhp
> t4$.d...@40tude.net>, Wed, 29 Aug 2012 02:48:28, tlvp
> <mPiOsUcB...@att.net> posted:
>
> >As well as the two ideas Jukka posted that I wish were easier to realize,
> >viz., the @font font-embedding, and the "use their Unicode code-points as
> >HTML character entities and pray your visitors' browsers support that"
> >approaches, there's the possibility of making tiny little .PNG graphics,
> >one per character, and using those as in-line images (with both alt="" and
> >title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
>
> To that one should add "and sized in ex units", in which case they will
> Zoom with the ordinary text using Firefox, Zoom Text Only.
>
> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
Why not em units? Is there some fundamental difference in the
> In comp.infosystems.www.authoring.html message <1g8w3h0kkxzbu.dlw804qnhp
> t4$.d...@40tude.net>, Wed, 29 Aug 2012 02:48:28, tlvp
> <mPiOsUcB...@att.net> posted:
>
> >As well as the two ideas Jukka posted that I wish were easier to realize,
> >viz., the @font font-embedding, and the "use their Unicode code-points as
> >HTML character entities and pray your visitors' browsers support that"
> >approaches, there's the possibility of making tiny little .PNG graphics,
> >one per character, and using those as in-line images (with both alt="" and
> >title="" text telling things like "UC Fraktur A", "LC Fraktur m", etc.
>
> To that one should add "and sized in ex units", in which case they will
> Zoom with the ordinary text using Firefox, Zoom Text Only.
>
> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
operation of zoom function between text in em and ex units?
John W Kennedy
Aug 31, 2012, 12:31:31 PM8/31/12
to
in your head, ex is more likely to give you what you actually want.
--
John W Kennedy
"The whole modern world has divided itself into Conservatives and
Progressives. The business of Progressives is to go on making mistakes.
The business of the Conservatives is to prevent the mistakes from being
corrected."
-- G. K. Chesterton
Jukka K. Korpela
Aug 31, 2012, 12:48:04 PM8/31/12
to
2012-08-31 19:31, John W Kennedy wrote:
>> Why not em units? Is there some fundamental difference in the
>> operation of zoom function between text in em and ex units?
>
> None, but if you're not a professional typesetter and you're estimating
> in your head, ex is more likely to give you what you actually want.
This is really about CSS, not HTML. Anyway, in the original context,
>> Why not em units? Is there some fundamental difference in the
>> operation of zoom function between text in em and ex units?
>
> None, but if you're not a professional typesetter and you're estimating
> in your head, ex is more likely to give you what you actually want.
where uppercase Fraktur letters were discussed, the em unit is more
natural. There is no fixed relationship between em, the font size, and
the height of uppercase letters, but it�s still more natural to relate
uppercase letters to em than to ex, which is specifically about
lowercase letters.
The major practical issue with ex is that some browsers treat is as
actually standing for the x-height, whereas some other browsers treat
1ex just as 0.5em.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Dr J R Stockton
Sep 1, 2012, 2:30:36 PM9/1/12
to
In comp.infosystems.www.authoring.html message <no.email-EB8C2A.09004331
082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
Stone <no.e...@domain.invalid> posted:
>> To that one should add "and sized in ex units", in which case they will
>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>
>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>
>Why not em units? Is there some fundamental difference in the
>operation of zoom function between text in em and ex units?
I'd expect people here to assume that they behave in the same way. The
cited page shows that there are other possibilities, rem & ch, and that
current Firefox understands them.
However, the ex unit is smaller, giving more resolution per decimal
digit; and, since matching height is more important, it seems more
fitting to use ex.
When matters are basically evenly balanced, the scale may be turned by
minor considerations.
--
082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
Stone <no.e...@domain.invalid> posted:
>> To that one should add "and sized in ex units", in which case they will
>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>
>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>
>Why not em units? Is there some fundamental difference in the
>operation of zoom function between text in em and ex units?
cited page shows that there are other possibilities, rem & ch, and that
current Firefox understands them.
However, the ex unit is smaller, giving more resolution per decimal
digit; and, since matching height is more important, it seems more
fitting to use ex.
When matters are basically evenly balanced, the scale may be turned by
minor considerations.
--
Jukka K. Korpela
Sep 2, 2012, 10:33:18 AM9/2/12
to
2012-09-01 21:30, Dr J R Stockton wrote:
> In comp.infosystems.www.authoring.html message <no.email-EB8C2A.09004331
> 082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
> Stone <no.e...@domain.invalid> posted:
>
>>> To that one should add "and sized in ex units", in which case they will
>>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>>
>>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>>
>> Why not em units? Is there some fundamental difference in the
>> operation of zoom function between text in em and ex units?
>
> I'd expect people here to assume that they behave in the same way.
They behave the same way in zooming, but they are quite different units.
> In comp.infosystems.www.authoring.html message <no.email-EB8C2A.09004331
> 082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
> Stone <no.e...@domain.invalid> posted:
>
>>> To that one should add "and sized in ex units", in which case they will
>>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>>
>>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>>
>> Why not em units? Is there some fundamental difference in the
>> operation of zoom function between text in em and ex units?
>
> I'd expect people here to assume that they behave in the same way.
The ex unit nominally indicates the x-height, which is defined in CSS as
the height of lowercase letters without descenders and ascenders (such
as "x"), though typographically this is not quite accurate. What's
important is that some browsers get this right, some don't - the latter
take 1ex simply as 0.5em. Though 1ex is about 0.5em in the average,
using the simple rule nullifies the very idea of ex.
So the em unit is more consistent.
In this discussion, the specific characters discussed were uppercase
Fraktur letters. I would say that the em unit is more descriptive then.
For lowercase Fraktur, things might be different in principle, but the
consistency aspect favors the em unit.
You would still need to analyze the intended copy text font and find a
multiplier of em that approximates the height of its uppercase letters.
> The
> cited page shows that there are other possibilities, rem & ch, and that
> current Firefox understands them.
useless here. The rem unit is meant for situations where you have nested
elements with font size settings and you find it difficult to keep track
or their net effect (and therefore prefer using the root em unit). The
ch unit stands for the width of the digit '0', so it's a poor candidate
for using with heights.
> However, the ex unit is smaller, giving more resolution per decimal
> digit;
multiplier.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Dr J R Stockton
Sep 3, 2012, 2:11:40 PM9/3/12
to
In comp.infosystems.www.authoring.html message <k1vqne$67h$1@dont-
email.me>, Sun, 2 Sep 2012 17:33:18, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-09-01 21:30, Dr J R Stockton wrote:
>
>> In comp.infosystems.www.authoring.html message <no.email-EB8C2A.09004331
>> 082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
>> Stone <no.e...@domain.invalid> posted:
>>
>>>> To that one should add "and sized in ex units", in which case they will
>>>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>>>
>>>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>>>
>>> Why not em units? Is there some fundamental difference in the
>>> operation of zoom function between text in em and ex units?
>>
>> I'd expect people here to assume that they behave in the same way.
>
>They behave the same way in zooming, but they are quite different units.
>
>The ex unit nominally indicates the x-height, which is defined in CSS
>as the height of lowercase letters without descenders and ascenders
>(such as "x"), though typographically this is not quite accurate.
>What's important is that some browsers get this right, some don't - the
>latter take 1ex simply as 0.5em. Though 1ex is about 0.5em in the
>average, using the simple rule nullifies the very idea of ex.
>
>So the em unit is more consistent.
>
>In this discussion, the specific characters discussed were uppercase
>Fraktur letters. I would say that the em unit is more descriptive then.
>For lowercase Fraktur, things might be different in principle, but the
>consistency aspect favors the em unit.
I'd expect people here to know all about that.
current computers.
>> The
>> cited page shows that there are other possibilities, rem & ch, and that
>> current Firefox understands them.
>
>They are CSS3 novelties that lack universal support, and they are
>rather useless here. The rem unit is meant for situations where you
>have nested elements with font size settings and you find it difficult
>to keep track or their net effect (and therefore prefer using the root
>em unit). The ch unit stands for the width of the digit '0', so it's a
>poor candidate for using with heights.
>
>> However, the ex unit is smaller, giving more resolution per decimal
>> digit;
>
>I don't see how the size would matter. You can use any number as the
>multiplier.
Clearly you are a theoretician and not a metrologist. Depending on the
actual size of the imaged character within the image itself, one will
need either two or three decimal digits to get a reasonably good size
match. I used 0.57em, and about 1.14ex would have done as well. But I
think that a more adept character-copier than I am would have used a
moderately larger image, such that to get sufficient accuracy one more
decimal digit is likely to be needed when using em in comparison with
ex. Saving one character is unimportant; but if matters are otherwise
evenly balanced one might as well do it.
However, as I wrote, I use {\frak A} which works very well and is
automatically of a suitable size. ... ... H'mmm - all learned Finns are
good at English (the better sort, in UK English) - do you know any who
are good at c.18 Latin (as Euler wrote) and are not afraid of the
mathematics?
email.me>, Sun, 2 Sep 2012 17:33:18, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-09-01 21:30, Dr J R Stockton wrote:
>
>> In comp.infosystems.www.authoring.html message <no.email-EB8C2A.09004331
>> 082...@news.eternal-september.org>, Fri, 31 Aug 2012 09:00:43, David
>> Stone <no.e...@domain.invalid> posted:
>>
>>>> To that one should add "and sized in ex units", in which case they will
>>>> Zoom with the ordinary text using Firefox, Zoom Text Only.
>>>>
>>>> <http://www.merlyn.demon.co.uk/www-use1.htm#ZTO2> refers.
>>>
>>> Why not em units? Is there some fundamental difference in the
>>> operation of zoom function between text in em and ex units?
>>
>> I'd expect people here to assume that they behave in the same way.
>
>They behave the same way in zooming, but they are quite different units.
>
>The ex unit nominally indicates the x-height, which is defined in CSS
>as the height of lowercase letters without descenders and ascenders
>(such as "x"), though typographically this is not quite accurate.
>What's important is that some browsers get this right, some don't - the
>latter take 1ex simply as 0.5em. Though 1ex is about 0.5em in the
>average, using the simple rule nullifies the very idea of ex.
>
>So the em unit is more consistent.
>
>In this discussion, the specific characters discussed were uppercase
>Fraktur letters. I would say that the em unit is more descriptive then.
>For lowercase Fraktur, things might be different in principle, but the
>consistency aspect favors the em unit.
>
>You would still need to analyze the intended copy text font and find a
>multiplier of em that approximates the height of its uppercase letters.
Very easy, by successive approximation testing, with the speed of
>You would still need to analyze the intended copy text font and find a
>multiplier of em that approximates the height of its uppercase letters.
current computers.
>> The
>> cited page shows that there are other possibilities, rem & ch, and that
>> current Firefox understands them.
>
>They are CSS3 novelties that lack universal support, and they are
>rather useless here. The rem unit is meant for situations where you
>have nested elements with font size settings and you find it difficult
>to keep track or their net effect (and therefore prefer using the root
>em unit). The ch unit stands for the width of the digit '0', so it's a
>poor candidate for using with heights.
>
>> However, the ex unit is smaller, giving more resolution per decimal
>> digit;
>
>I don't see how the size would matter. You can use any number as the
>multiplier.
actual size of the imaged character within the image itself, one will
need either two or three decimal digits to get a reasonably good size
match. I used 0.57em, and about 1.14ex would have done as well. But I
think that a more adept character-copier than I am would have used a
moderately larger image, such that to get sufficient accuracy one more
decimal digit is likely to be needed when using em in comparison with
ex. Saving one character is unimportant; but if matters are otherwise
evenly balanced one might as well do it.
However, as I wrote, I use {\frak A} which works very well and is
automatically of a suitable size. ... ... H'mmm - all learned Finns are
good at English (the better sort, in UK English) - do you know any who
are good at c.18 Latin (as Euler wrote) and are not afraid of the
mathematics?
Jukka K. Korpela
Sep 4, 2012, 1:10:29 AM9/4/12
to
2012-09-03 21:11, Dr J R Stockton wrote:
> I'd expect people here to know all about that.
So why did you quote it? Comprehensive quoting generally indicates lack
> I'd expect people here to know all about that.
of comprehensive reading. And you are now saying that you expect (quite
unrealistically, I would say) that people know all about the points why
em is better in a specific case than ex. So I wonder why you recommended ex.
>> You would still need to analyze the intended copy text font and find a
>> multiplier of em that approximates the height of its uppercase letters.
>
> Very easy, by successive approximation testing, with the speed of
> current computers.
easily skip such things, making some guess. And it's not _quite_ that
simple. Having decided on a list of fonts, or "font stack", you would
need to analyze the fonts and choose some suitable value, based on
different considerations (including educated guesses on how often some
font will be used etc.).
>> I don't see how the size would matter. You can use any number as the
>> multiplier.
>
> Clearly you are a theoretician and not a metrologist. Depending on the
> actual size of the imaged character within the image itself, one will
> need either two or three decimal digits to get a reasonably good size
> match.
> Saving one character is unimportant;
> However, as I wrote, I use {\frak A} which works very well
it, so let's not get distracted.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Dr J R Stockton
Sep 5, 2012, 2:33:57 PM9/5/12
to
In comp.infosystems.www.authoring.html message <k242g6$f73$1@dont-
email.me>, Tue, 4 Sep 2012 08:10:29, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-09-03 21:11, Dr J R Stockton wrote:
>
>> I'd expect people here to know all about that.
>
>So why did you quote it? Comprehensive quoting generally indicates lack
>of comprehensive reading. And you are now saying that you expect (quite
>unrealistically, I would say) that people know all about the points why
>em is better in a specific case than ex.
No; you should read what I wrote more carefully.
>So I wonder why you recommended ex.
>
>>> You would still need to analyze the intended copy text font and find a
>>> multiplier of em that approximates the height of its uppercase letters.
>>
>> Very easy, by successive approximation testing, with the speed of
>> current computers.
>
>I didn't say it was difficult, just that it has to be done, and people
>easily skip such things, making some guess. And it's not _quite_ that
>simple. Having decided on a list of fonts, or "font stack", you would
>need to analyze the fonts and choose some suitable value, based on
>different considerations (including educated guesses on how often some
>font will be used etc.).
If readers do not use a font whose metrics are not sufficiently similar
to Times New Roman, then that's their problem. My site offers free
information, and describes its author's settings; I'm not trying to
peddle products for profit.
>>> I don't see how the size would matter. You can use any number as the
>>> multiplier.
>>
>> Clearly you are a theoretician and not a metrologist. Depending on the
>> actual size of the imaged character within the image itself, one will
>> need either two or three decimal digits to get a reasonably good size
>> match.
>
>I find it difficult to believe that you are serious here.
>
>> Saving one character is unimportant;
>
>Yes indeed, both theoretically and practically.
>
>> However, as I wrote, I use {\frak A} which works very well
>
>Fine, but you asked about the HTML alternative, and we are discussing
>it, so let's not get distracted.
Actually, I did not ask about an alternative, since I did not at that
time know about the MathJax way. And they should only be called
alternatives if there is certainty that no further ways exist.
You are the only one who seems interested in discussing it now.
--
(c) John Stockton, nr London, UK. Mail via homepage. Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
email.me>, Tue, 4 Sep 2012 08:10:29, Jukka K. Korpela
<jkor...@cs.tut.fi> posted:
>2012-09-03 21:11, Dr J R Stockton wrote:
>
>> I'd expect people here to know all about that.
>
>So why did you quote it? Comprehensive quoting generally indicates lack
>of comprehensive reading. And you are now saying that you expect (quite
>unrealistically, I would say) that people know all about the points why
>em is better in a specific case than ex.
>So I wonder why you recommended ex.
>
>>> You would still need to analyze the intended copy text font and find a
>>> multiplier of em that approximates the height of its uppercase letters.
>>
>> Very easy, by successive approximation testing, with the speed of
>> current computers.
>
>I didn't say it was difficult, just that it has to be done, and people
>easily skip such things, making some guess. And it's not _quite_ that
>simple. Having decided on a list of fonts, or "font stack", you would
>need to analyze the fonts and choose some suitable value, based on
>different considerations (including educated guesses on how often some
>font will be used etc.).
to Times New Roman, then that's their problem. My site offers free
information, and describes its author's settings; I'm not trying to
peddle products for profit.
>>> I don't see how the size would matter. You can use any number as the
>>> multiplier.
>>
>> Clearly you are a theoretician and not a metrologist. Depending on the
>> actual size of the imaged character within the image itself, one will
>> need either two or three decimal digits to get a reasonably good size
>> match.
>
>I find it difficult to believe that you are serious here.
>
>> Saving one character is unimportant;
>
>Yes indeed, both theoretically and practically.
>
>> However, as I wrote, I use {\frak A} which works very well
>
>Fine, but you asked about the HTML alternative, and we are discussing
>it, so let's not get distracted.
time know about the MathJax way. And they should only be called
alternatives if there is certainty that no further ways exist.
You are the only one who seems interested in discussing it now.
--
(c) John Stockton, nr London, UK. Mail via homepage. Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
0 new messages