How do I evaluate a logic expression entered at run time?

[Thomas G. Marshall]

Roedy Green coughed up:

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]

Thomas G. Marshall coughed up:

Roedy Green coughed up:

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.

--
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.

 

[Raymond DeCampo]

Raymond DeCampo coughed up:



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

 

[Thomas G. Marshall]

Raymond DeCampo coughed up:

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.

 

[Thomas G. Marshall]

Thomas G. Marshall coughed up:

Raymond DeCampo coughed up:


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.

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[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.