per-character font base adjustment

[paramucho]

Is there some method I can use to adjust the font-base on a
per-character basis?

For example, I sometimes need to have the text "1234" such that the
sequence ascends on the page:

4
3
2
1

but at a scan-line at a time (rather than a character line as in the
example above).

I've beaten my head up against various walls trying to use CSS type
sequences to do this, but either I'm getting it wrong (which is highly
likely) or the renderers just don't expect this kind of behaviour.

I recall seeing webpages where they handle similar kinds of font
problems with in-line GIF/JPG graphics but I haven't been able to find
a tool which helps automate the process.

Any help or pointers to information would be greatly appreciated.


Ian

 

[Toby Inkster]

For example, I sometimes need to have the text "1234" such that the
sequence ascends on the page:

4
3
2
1

You mean like this?

<style type="text/css">
P.ascend SPAN
{
position: relative;
top: 0;
left: 0;
}
</style>

<p class="ascend">
<span style="bottom:-2px">1</span>
<span>2</span>
<span style="bottom:2px">3</span>
<span style="bottom:4px">4</span>
</p>

 

[paramucho]

You mean like this?

<style type="text/css">
P.ascend SPAN
{
position: relative;
top: 0;
left: 0;
}
</style>

<p class="ascend">
<span style="bottom:-2px">1</span>
<span>2</span>
<span style="bottom:2px">3</span>
<span style="bottom:4px">4</span>
</p>

That looks great and much simpler than what I came up with. But it
doesn't work for me if I plug it into an HTML wrapper and open it with
IE V5.50 (or Outlook Express for that matter).

Maybe I'm doing something stupid.

 

[rf]

paramucho wrote:

[ascending numbers]

That looks great and much simpler than what I came up with. But it
doesn't work for me if I plug it into an HTML wrapper and open it with
IE V5.50 (or Outlook Express for that matter).

Possibly because of the somewhat contradictory style properties Toby used,
top: in the head bit and bottom: in the inline bit.

Remove the top: 0 property/value pair in the head bit and it works
correctly. Better yet, replace the bottom: bits in the inline styles with
top and then everything will be consistent, that is if you reverse the signs
on the numbers.

BTW this is exactly what position: relative was designed for. Superscripting
and stuff.

Cheers
Richard.

 

[Jukka K. Korpela]

Is there some method I can use to adjust the font-base on a
per-character basis?

I don't find the word "font-base" in HTML or CSS specifications. What does
it mean, in HTML or CSS terms?

For example, I sometimes need to have the text "1234" such that the
sequence ascends on the page:

4
3
2
1

You mean as superscripts?

You could use vertical-align and font-size in CSS, to affect the vertical
placement and size (which is usually by default some reduced size for

but at a scan-line at a time (rather than a character line as in the
example above).

What's a "scan-line" and what's a "character line"?

What's the general idea behind such rendering, and how would you like it to
work in text-only browsing, speech browser, or in Braille rendering?
Specifically, is this all about visual appearance only, or does the
information content diminish if you use just "1234"?

 

[Safalra]

I don't find the word "font-base" in HTML or CSS specifications. What does
it mean, in HTML or CSS terms?

I presume you are being pedantic here, as he's clearly talking about
the baseline. Is there a problem using a typographical term (rather
than an HTML/CSS term) when talking about fonts?

What's a "scan-line" and what's a "character line"?

Once more I presume you are being pedantic and trying to subtley point
out that these terms have no meaning on a non-graphical display.

What's the general idea behind such rendering, and how would you like it to
work in text-only browsing, speech browser, or in Braille rendering?
Specifically, is this all about visual appearance only, or does the
information content diminish if you use just "1234"?

That's a good question. (I'm just pointing that out so that it's clear
this post isn't a personal attack, just an attack on pedantry.)

I suspect however that now the original poster has an answer that's to
his satisfaction he won't care if he's been asking the wrong question
all along, and he'll never find out that there's a far better solution
to his problems. I hope to be proved wrong, of course, but Usenet has
made me cynical.

 

[Toby Inkster]

Possibly because of the somewhat contradictory style properties Toby used,
top: in the head bit and bottom: in the inline bit.

Dammit!

Strike "bottom:" from my previous post, and replace with "top:".

Should be:

<style type="text/css">
P.ascend SPAN
{
position: relative;
top: 0;
left: 0;
}
</style>

<p class="ascend">
<span style="top:-2px">1</span>
<span>2</span>
<span style="top:2px">3</span>
<span style="top:4px">4</span>
</p>

Really, you guys should know better than to take any notice of my pre-9am
posts.

 

[Jukka K. Korpela]

I presume you are being pedantic here, as he's clearly talking about
the baseline.

No, I'm not pedantic here. It might be about the baseline, but that concept
is more complicated than people think. How can we know it's about baseline
and not bottom of text, for example?

Is there a problem using a typographical term (rather
than an HTML/CSS term) when talking about fonts?

Perhaps, if the term is vague or does not relate to (HTML or) CSS.
In this case, it was not a term at all (or it is, but means something
completely different from the intended meaning).

Once more I presume you are being pedantic and trying to subtley point
out that these terms have no meaning on a non-graphical display.

No, and not only. Again, the phrases are neither common typography terms
nor HTML or CSS terms.

That's a good question. (I'm just pointing that out so that it's clear
this post isn't a personal attack, just an attack on pedantry.)

An attack on assumed pedantry, to be exact.

I suspect however that now the original poster has an answer that's to
his satisfaction he won't care if he's been asking the wrong question
all along,

Quite possible. This is Usenet, a rich supply of right answers that are
worse than useless since you asked the wrong question, as well as wrong
answers of course.

and he'll never find out that there's a far better solution
to his problems.

Quite possible. After all, we don't know what the problem really is.

 

[paramucho]

Dammit!

Strike "bottom:" from my previous post, and replace with "top:".

Should be:

<style type="text/css">
P.ascend SPAN
{
position: relative;
top: 0;
left: 0;
}
</style>

<p class="ascend">
<span style="top:-2px">1</span>
<span>2</span>
<span style="top:2px">3</span>
<span style="top:4px">4</span>
</p>

Really, you guys should know better than to take any notice of my pre-9am
posts.

Very cool.

Now all I need to do is write the conversion software to take the base
material from RTF to HTML -- but that's relatively easy.

Many thanks.

 

[paramucho]

I presume you are being pedantic here, as he's clearly talking about
the baseline. Is there a problem using a typographical term (rather
than an HTML/CSS term) when talking about fonts?


Once more I presume you are being pedantic and trying to subtley point
out that these terms have no meaning on a non-graphical display.


That's a good question. (I'm just pointing that out so that it's clear
this post isn't a personal attack, just an attack on pedantry.)

I suspect however that now the original poster has an answer that's to
his satisfaction he won't care if he's been asking the wrong question
all along, and he'll never find out that there's a far better solution
to his problems. I hope to be proved wrong, of course, but Usenet has
made me cynical.

I have only dabbled in HTML -- there's a lot of it to learn and I
don't have the time available to conquer it all in one big block,
although I try to keep up to date with developments and I'm slowly
working my way through the large spec on the web. It's not an easy
document to work with a bit at a time.

I've read up on the philosophy of HTML -- and I think it's a great
boon to have it established in the world's predominant document
standard. However, there are some specialist areas which are hard to
translate into all the various rendering methods. But there's an
on-going process of evolution which is incrementally capturing more
and more territory as time goes by.

HTML has become a huge standard. The ability to easily convert to and
from HTML makes it the best choice for some applications that have
little to do with the original goals. It's a measure of the success of
HTML. For example, I wrote a little word processor for an old
mini-computer last year. I needed to store just enough information to
handle bold, bullets and the like. HTML was the obvious choice because
of the portability factor. But what I wrote was a word processor, not
a generic document renderer. The point is that HTML is flexible enough
to be retuned for that kind of app (i.e. applying word processor
behaviour to bullet sections etc).

To come to your point: my main activity is writing about music. I use
block and in-line examples -- thousands of them. The *right* question
that I should have asked is: how do I efficiently render music in
HTML, but I don't think there's anything out there to help me in a
practical sense. I compromise with some crude techniques and that's
where I use the baseline manipulation. I do my writing in an RTF app
where I use the baseline technique, so I'll put together a converter
to produce the HTML (there's a common template for the documents).

 

[Safalra]

I suspect however that now the original poster has an answer that's to
his satisfaction he won't care if he's been asking the wrong question
all along, and he'll never find out that there's a far better solution
to his problems. I hope to be proved wrong, of course, but Usenet has
made me cynical.

[snip]
To come to your point: my main activity is writing about music. I use
block and in-line examples -- thousands of them. The *right* question
that I should have asked is: how do I efficiently render music in
HTML, but I don't think there's anything out there to help me in a
practical sense. I compromise with some crude techniques and that's
where I use the baseline manipulation. I do my writing in an RTF app
where I use the baseline technique, so I'll put together a converter
to produce the HTML (there's a common template for the documents).

The problem here is that HTML was designed to mark-up text, not music.
Using CSS to shift notes around results in an unintelligible mess on
non-CSS user-agents (or those with CSS bugs). The best way of
marking-up music is disputed, but one way I like is Lilypond. You start
off with some XML:

<music>
\notes \relative c' {
e16-.->a(b gis)a-.->c(d b)c-.->e(f dis)e-.->a(b a)
gis(b e)e,(gis b)b,(e gis)gis,(b e)e,(gis? b e)
}
</music>

And it turns it to a PNG image with a link to a MIDI version. Take a
look at this Wikipedia entry for more:

http://meta.wikimedia.org/wiki/Music_markup#Lilypond

 

[Safalra]

An attack on assumed pedantry, to be exact.

I apologise for misinterpreting your comments. In retrospect I was
rather impolite. Wiio's laws in effect again...

Quite possible. After all, we don't know what the problem really is.

It seems my cynicism was unjustified - the original poster has
responded with his true problem. And it seems he's commited to "the
philosophy of HTML". There is hope for us all yet...

 

[rf]

paramucho wrote:

[snippity snip snip]

To come to your point:

Phew, at last

my main activity is writing about music.

What sort of music?

Most guitar music published on the web uses tabs. Google for [guitar tabs].
After a short learning curve these are as easy to read as "real" music,
sometimes easier as they are really a sort of three dimensional picture of
the music: time, string, fret. One can actually see the chords, just like
in real music.

OTOH if you are publishing a violin concerto then all bets are off. You are
better off with a PDF.

I would be most interested in viewing one of your RTF files. URL?

Cheers
Richard.

 

[Jukka K. Korpela]

The problem here is that HTML was designed to mark-up text, not music.

Indeed, but some notations of music can be regarded as text. After all,
there are even Unicode characters for notes and other symbols used for
writing down music.

Using CSS to shift notes around results in an unintelligible mess on
non-CSS user-agents (or those with CSS bugs).

In most cases, yes, but using <sup> and <sub> markup may work in some
cases, though you would probably want to tune the vertical-alignment and
the font-size in CSS. The presentation could still make sense even without
CSS, though there are unavoidably situations where superscripting and
subscripting cannot work as such (character cell browsers, speech browsers,
Braille rendering, search engines). Clever browsers could still tell the
user about superscripting and subscripting.

Some approaches might use (gasp) tables, which might even have structural
meaning in musics notations.

Yet another possibility is Ruby markup, which wasn't really designed for
music but can be used to attach "interlinear annotations" to text (and has
some basic support on IE 6).