«

Roedy Green coughed up:
> On Thu, 25 Aug 2005 07:10:52 GMT, Andrew Thompson
> <> wrote or quoted :
>
>> Yes. ..And Roedy, I am surprised at you - I thought you
>> had more sense than to lock the font size (for the poor
>> IE users - most other browsers take those font sizes as
>> merely 'suggestions')
>
> I read a book about CSS and it pointed out the problems with every
> approach. I decided that px was the way to go to avoid trouble and
> also to make my applet displays consistent with the inline HTML
> displays.
>
> I have now flipped to "em"s, which was my second choice on reading the
> O'Reilly fish book, before reading your warning against it. We will
> see who screams now.
>
> Standards groups need to create validation suites, and sue anyone who
> calls their stuff X when it has not passed validation, getting tough
> like the Ada people did.
>
> The point needs to be redefined so that 12 point type will always
> appear psychologically the same size. 12 point type on a coarse
> resolution screen currently is bigger. Further different fonts
> nominally 12 point differ wildly in size even on the same screen. They
> need to be normalized.

They are: it's called /points/. Display postscript actually was the
display engine behind the NeXT screen. Sun had something similar
beforehand, but IIRC it was clumsy to use, and did not foreably unite "all"
access to the screen, like DP did.



>
> Applets need to automatically use bigger fonts (in terms of pixels) on
> a higher res screen when the angular size of the image stays the same.
>
> You need a single global control to deal with eyesight. You should
> not have to adjust every program separately to get a bigger image.



--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

Thomas G. Marshall coughed up:
> Roedy Green coughed up:
>> On Thu, 25 Aug 2005 07:10:52 GMT, Andrew Thompson
>> <> wrote or quoted :
>>
>>> Yes. ..And Roedy, I am surprised at you - I thought you
>>> had more sense than to lock the font size (for the poor
>>> IE users - most other browsers take those font sizes as
>>> merely 'suggestions')
>>
>> I read a book about CSS and it pointed out the problems with every
>> approach. I decided that px was the way to go to avoid trouble and
>> also to make my applet displays consistent with the inline HTML
>> displays.
>>
>> I have now flipped to "em"s, which was my second choice on reading
>> the O'Reilly fish book, before reading your warning against it. We
>> will see who screams now.
>>
>> Standards groups need to create validation suites, and sue anyone who
>> calls their stuff X when it has not passed validation, getting tough
>> like the Ada people did.
>>
>> The point needs to be redefined so that 12 point type will always
>> appear psychologically the same size. 12 point type on a coarse
>> resolution screen currently is bigger. Further different fonts
>> nominally 12 point differ wildly in size even on the same screen.
>> They need to be normalized.
>
> They are: it's called /points/. Display postscript actually was
> the display engine behind the NeXT screen. Sun had something similar
> beforehand,

NeWS


> but IIRC it was clumsy to use, and did not foreably unite
> "all" access to the screen, like DP did.
>
>
>
>>
>> Applets need to automatically use bigger fonts (in terms of pixels)
>> on a higher res screen when the angular size of the image stays the
>> same. You need a single global control to deal with eyesight. You should
>> not have to adjust every program separately to get a bigger image.



--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

Thomas G. Marshall wrote:
> Raymond DeCampo coughed up:
>
>>Roedy Green wrote:
>>
>>>You need a single global control to deal with eyesight. You should
>>>not have to adjust every program separately to get a bigger image.
>>
>>Wouldn't that be setting your screen resolution?
>
>
> Nope. Not all programs in windows are affected by this, particularly those
> exploiting bitmap fonts.
>
>
>

So you are saying that if one uses a bitmap font (which I will admit to
not knowing exactly what you mean by this), changing the screen
resolution from say 1600x1200 to 800x600 will not make the physical size
of the characters on the screen bigger?

Can you explain how this works? (I can imagine a few ways, but I would
like to know to actual way.) If the explanation is too lengthy or
off-topic, I'll understand.

I decided to google and wikipedia bitmap fonts before posting this, and
I have to admit I am more puzzled. According to wikipedia, "A bitmap
font is one that stores each glyph as an array of pixels (that is, a
bitmap)." Changing the screen resolution effectively makes the size of
each pixel bigger, so why are bitmap fonts immune?

Thanks,
Ray

--
XML is the programmer's duct tape.

Raymond DeCampo coughed up:
> Thomas G. Marshall wrote:
>> Raymond DeCampo coughed up:
>>
>>> Roedy Green wrote:
>>>
>>>> You need a single global control to deal with eyesight. You should
>>>> not have to adjust every program separately to get a bigger image.
>>>
>>> Wouldn't that be setting your screen resolution?
>>
>>
>> Nope. Not all programs in windows are affected by this,
>> particularly those exploiting bitmap fonts.
>>
>>
>>
>
> So you are saying that if one uses a bitmap font (which I will admit
> to not knowing exactly what you mean by this), changing the screen
> resolution from say 1600x1200 to 800x600 will not make the physical
> size of the characters on the screen bigger?
>
> Can you explain how this works? (I can imagine a few ways, but I
> would like to know to actual way.) If the explanation is too lengthy
> or off-topic, I'll understand.
>
> I decided to google and wikipedia bitmap fonts before posting this,
> and I have to admit I am more puzzled. According to wikipedia, "A
> bitmap font is one that stores each glyph as an array of pixels (that
> is, a bitmap)." Changing the screen resolution effectively makes the
> size of each pixel bigger, so why are bitmap fonts immune?
>
> Thanks,
> Ray


Well, it is confusing, and it doesn't help that I botched the answer
somewhat. I was responding to "large" vs. "small" vs. "huge" font settings
in the OS. This is a mistake on my part.

Well, here's the rub with the real issue you're talking about.

1. LCD monitor disaster: If you change the resolution at the driver level to
one that is not the hardware native resolution of your monitor your display
will be hideous. Thems the rules. Don't wanna go into why. No energy; too
much diet coke to think straight.

2. If you use the

Control Panel-->Display-->Settings-->Advanced-->DPI Setting:

and switch from what they consider to be the "normal size (96 dpi)", I've
discovered through trial and error that for many things even *this* does not
work. I've got no idea why. Furthermore, even when font smoothing is
turned off, everything degrades in quality. Again, no idea why.

I suspect its because that there are many things that drive graphics bit by
bit and bypass any layering, but {shrug} beats me.

It's basically as I said before: What the world really needed was a
resolution independent + device independent display processing language.
Display-Postscript was a pretty nifty solution, since it was designed
specifically to manage a desktop and all its windows, etc.


--
"Realtor" and "realty" are pronounced "reel'-tor" and
"reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!!
If you pronounce them with the extra syllable, you will
sound like a complete idiot.

Thomas G. Marshall coughed up:
> Raymond DeCampo coughed up:
>> Thomas G. Marshall wrote:
>>> Raymond DeCampo coughed up:
>>>
>>>> Roedy Green wrote:
>>>>
>>>>> You need a single global control to deal with eyesight. You
>>>>> should not have to adjust every program separately to get a
>>>>> bigger image.
>>>>
>>>> Wouldn't that be setting your screen resolution?
>>>
>>>
>>> Nope. Not all programs in windows are affected by this,
>>> particularly those exploiting bitmap fonts.
>>>
>>>
>>>
>>
>> So you are saying that if one uses a bitmap font (which I will admit
>> to not knowing exactly what you mean by this), changing the screen
>> resolution from say 1600x1200 to 800x600 will not make the physical
>> size of the characters on the screen bigger?
>>
>> Can you explain how this works? (I can imagine a few ways, but I
>> would like to know to actual way.) If the explanation is too lengthy
>> or off-topic, I'll understand.
>>
>> I decided to google and wikipedia bitmap fonts before posting this,
>> and I have to admit I am more puzzled. According to wikipedia, "A
>> bitmap font is one that stores each glyph as an array of pixels (that
>> is, a bitmap)." Changing the screen resolution effectively makes the
>> size of each pixel bigger, so why are bitmap fonts immune?
>>
>> Thanks,
>> Ray
>
>
> Well, it is confusing, and it doesn't help that I botched the answer
> somewhat. I was responding to "large" vs. "small" vs. "huge" font
> settings in the OS. This is a mistake on my part.
>
> Well, here's the rub with the real issue you're talking about.
>
> 1. LCD monitor disaster: If you change the resolution at the driver
> level to one that is not the hardware native resolution of your
> monitor your display will be hideous. Thems the rules. Don't wanna
> go into why. No energy; too much diet coke to think straight.
>
> 2. If you use the
>
> Control Panel-->Display-->Settings-->Advanced-->DPI Setting:
>
> and switch from what they consider to be the "normal size (96 dpi)",
> I've discovered through trial and error that for many things even
> *this* does not work. I've got no idea why. Furthermore, even when
> font smoothing is turned off, everything degrades in quality.

Note that I said "quality" here and not "resolution". I'm not complaining
that there are fewer dots to draw things. I'm complaining that they just
don't look "right" even so.

> Again,
> no idea why.
> I suspect its because that there are many things that drive graphics
> bit by bit and bypass any layering, but {shrug} beats me.
>
> It's basically as I said before: What the world really needed was a
> resolution independent + device independent display processing
> language. Display-Postscript was a pretty nifty solution, since it
> was designed specifically to manage a desktop and all its windows,
> etc.



--
"Realtor" and "realty" are pronounced "reel'-tor" and
"reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!!
If you pronounce them with the extra syllable, you will
sound like a complete idiot.

On Thu, 25 Aug 2005 12:19:53 GMT, Raymond DeCampo
<> wrote or quoted :

>Wouldn't that be setting your screen resolution?

That is an approximation. I think you should be able to make images
bigger without making them more grainy. You want all the help you can
get to aid vision.

It will get more difficult over time to change screen resolution. CRTs
are very flexible as to screen resolution. LCDs are not. Screen
resolution must exactly fit the pattern of little bars on the LCD
screen.

I read that 'digital paper' was coming something you could roll up in
a scroll that had 1200 dpi resolution, like typesetting.

Imagine what an Applet would look like displayed on digital paper in
amongst some HTML text, cranked up in size to be viewable. The
Applets will be like tiny rice paintings.

At some point Applets have to become resizable CSS elements -- either
by giving them more real estate that Applets use by increasing font
size, or by automatic scaling.

You have the same problem with desktop apps -- all tied to the
ever-shrinking pixel. John Warner saw this coming decades ago when he
invented PostScript. Java could not go the DisplayPostscript route,
though for a while it looked with Bravo that they would. I think Sun
realised their bread and butter might come eventually from devices too
tiny to support it.


--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On Thu, 25 Aug 2005 16:15:39 GMT, "Thomas G. Marshall"
<. com> wrote or quoted
:

>They are: it's called /points/.

Except they are not defined that way in Java. A point in Java is the
same as a pixel.

It seems to me way back circa 1990 I was writing windows C code where
we designed in something called "dialog units" which was a reasonable
solution to the problem, at least for dialog boxes.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On Thu, 25 Aug 2005 09:23:48 +0100, TechBookReport <>
wrote or quoted :

>> See http://mindprod.com/jgloss/eval.html
>
>Roedy, you're missing the URL to your JEP page.

I just checked it. All seems ok.

You click JEP it takes you to the JEP entry in the glossary.
Click on the main green link to take you to the JEP home page.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

[Fathzer]

I had to solve a similar problem (on vectors of booleans) and found nothing that suits my needs.
I've just released the infix parser I wrote : Javaluator (http://javaluator.sourceforge.net).
See the tutorial to have an example of how to evaluate boolean expressions.