Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How do I evaluate a logic expression entered at run time?

Reply
Thread Tools

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

 
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-25-2005
Roedy Green coughed up:
> On Thu, 25 Aug 2005 07:10:52 GMT, Andrew Thompson
> <(E-Mail Removed)> 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.


 
Reply With Quote
 
 
 
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-25-2005
Thomas G. Marshall coughed up:
> Roedy Green coughed up:
>> On Thu, 25 Aug 2005 07:10:52 GMT, Andrew Thompson
>> <(E-Mail Removed)> 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.


 
Reply With Quote
 
 
 
 
Raymond DeCampo
Guest
Posts: n/a
 
      08-25-2005
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.
 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-25-2005
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.


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      08-25-2005
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.


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-30-2005
On Thu, 25 Aug 2005 12:19:53 GMT, Raymond DeCampo
<(E-Mail Removed)> 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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-30-2005
On Thu, 25 Aug 2005 16:15:39 GMT, "Thomas G. Marshall"
<(E-Mail Removed). 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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-30-2005
On Thu, 25 Aug 2005 09:23:48 +0100, TechBookReport <(E-Mail Removed)>
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.
 
Reply With Quote
 
Fathzer Fathzer is offline
Junior Member
Join Date: Aug 2012
Posts: 1
 
      08-29-2012
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python Logic Map/Logic Flow Chart. (Example Provided) spike Python 8 02-09-2010 12:31 PM
Asynchronous Logic Gates and Analog Logic Gates Jyoti Ballabh Software 3 11-26-2009 06:48 PM
Evaluate Checkboxes entered at Runtime Michael Haberfellner ASP .Net 2 03-06-2007 08:27 AM
How to explain "evaluate the expression as a void expression"? Jason luo C Programming 3 08-19-2004 12:43 AM
Date entered from textbox becomes null (1/1/1900) when entered into SQL table. TN Bella ASP .Net 1 07-01-2004 02:53 PM



Advertisments