LabVIEW Idea Exchange

[#1]

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

Idea -->LabVIEW should also standardize here!

[#2]

It seems that LabVIEW is actually specifying the font size in pixels rather than points.  A point is rather rigorously defined as 1/72 of an inch.  Left to its own devices, Windows assumes a monitor pitch of 96 dpi.  So a 72 point font should be 1 inch or 96 pixels tall. LabVIEW thinks it should be 72 pixels tall, so it winds up about 25% smaller than what everyone else thinks.

The Mac OS has a long tie to graphic artists, so I assume that is why they assumed 72 dpi for the monitor pitch, no need to fuss around.  LabVIEW was born on the Mac and brought to the PC. Since the font handling apparently hasn't changed in twenty plus years, they probably never got around to doing the scaling that other Windows programs do.

On the Mac I used to use 9 and 10 point fonts with LV, I'd be squinty if I tried that with LV on Windows...

All of that said, I am not sure what I would suggest NI do.  When I use the picture control, I can count on the height of the textbox being equal to the "point" size I choose for the font.  On the other hand, my FPs look different on every different sized monitor.  Should NI adopt a somewhat arbitrary Microsoft hack?  Or, just change the unit from pt to px?  I am inclined to say, move to all vector drawing based on the actual screen dimensions and resolution.  The chances of that seem slim, but how many half-measures make up the full measure?

Three choices here:  Do nothing (no), adopt Microsoft standard (better than nothing), change unit to px (accurate at least, explains difference).

[#3]

Of the 3 choices Darin mentioned, I'd be most in favor of #3: changing "pt" to "px." It's the simplest, fastest and easiest to implement, and it doesn't break FPs on any OS.

[#4]

Obviously, the fonts on windows are optimized for the local assumptions on dpi, etc. That's probably also the reason why all the integer sizes scale so well. Converted to the LabVIEW definition, We often get really jumpy behavior (8/9 14/15, 19/20 and are basically the same, and there is a gigantic jump between 13 and 14, right in the size range where we want to fine-tune the size. It is always irritating when I do a ctrl+ or ctrl- and, for some steps, only the vertical spacing changes while for other steps there is a large jump in size.

I would not like a definition in pixels, because it probably won't scale well in the future. (Maybe the next generation of displays has a 10x finer pitch).

I really don't know what the best solution is, but font issues are one of the biggest problems in LabVIEW. We need a way to ensure WTPSIWTUG (What the programmer sees is what the user gets). Font's should never be tied to the windows theme or OS settings, for example. Maybe there should even be an option to embed unusual fonts in the VI for portability.

[#5]

Kudos!  Back to my old rant.  NI needs a MAJOR overhaul of it's Front Panel "EVERYTHING"... not just patches or assorted improvements.  A good lesson in Standards of the current technology would help too.  NI is the best at most everything it does... but certainly not the FP.

[#6]

Another problem is in the case where company requirements dictate certain font sizes for the user interface for software written in any language.

Obvioulsy, the LabVIEW group would need to get special clearance to use different font sizes so the results conform. The size conversion routines would need to get specified.

[#7]

Something I'd like to see would be a way to set the "default font size" for a Project.  I know (because I've read the Discussion Groups) that it is possible to set the "global default fonts" by messing with the LabVIEW.ini file within Program Files, but that is both "dangerous" (who wants to mess around in there?) and clumsy (digging under the covers, non-intuitive, etc.).

What I'd like to see is a setting within a Project (so that it changes with each Project) that allows you to specify a fixed Font size (and possibly the font, itself, along with attributes).  One option for each setting should be "Default" (which is the current de facto standard).  But when you do want to set it for a particular Project, it would be nice to be able to do so!

I'm moving some old code, developed in LabVIEW 7.0 on a Windows XP system, to LabVIEW 2010 on Windows 7.  I noticed that many of my Front Panel controls look really ugly, with controls overlapping labels.  I started trying to "move them all around", and just realized the problem was that the default Font Size is probably one point bigger!  I do not want to change LabVIEW.ini for this one task ...

Seems to me this suggestion (assuming the implementation is relatively straight-forward) would solve lots of problems for lots of LabVIEW programmers, but would have minimal negative impact as one could always get the current behavior by using the Default setting.