You know how text turns into little boxes when you zoom out too far? That’s “greeking”
Why do you care? Well, how much times does “greeking” waste?
If you had a bigger display, could you save time?
Could an analysis of your systems susceptibility to “greeking” justify a larger monitor?
Dell Pricing as o4/26/08:
- $339 = 1680×1050 (2208 widescreen)
- $699 = 1920×1200 (2408 widescreen)
- $1274 = 2560×1600 (3007 widescreen)
Pro/E will “greek” text whenever it’s forced to render text with less than 4 actual pixels. Not that you can actually read the primitive 4 pixel representation, but boxes will appear at any rendering less than 4 pixels high. Here’s the approximate pixel math:
Text height / drawing size = 4 pixels / height of rendered drawing. A simple proportion that is influenced by several factors:
- Physical display size – Let’s try to see what costs and benefits are associated with different size monitors.
- Software – Pro/E has an odd quirk that can reduce your efficiency when working with B and D size drawings.
- User management – You could be making things worse by increasing window overhead.
As I reported before, my place of business recently replaced 3 year old 4:3 displays with new 16:10 widescreen displays. Supposedly, all 20″ diagonal measurement, and therefore equivalent. Unfortunately for Pro/E users, the reduction in vertical height from 1200 to 1050 removes 150 pixels from the workspace net height. The new widescreens are almost a step back to the old 1280×1024 displays. In order to restore my ability to read the same size text on a widescreen display, a 24″ replacement should have been specified.
If you’ve looked at my mapkeys in the past, you might have noticed that I use the standard refit command in several places. PTC’s current refit algorithm fits the drawing horizontally in a default window with the model tree window open, but doesn’t adjust completely when the model tree is closed. And, when the Pro/E window is maximized, the fit gets even worse – over 20% of the useable screen height is wasted.
Drafters need lots of real estate and fast hidden line removal, and not being able to open the drawing window to full screen is a major compromise. So, until I can justify a larger monitor, I’ve come up with this “improved” refit mapkey. It basically zooms in after a refit by a factor of .3 (trial and error).
mapkey zd %~refit; ~ Activate `main_dlg_cur` `psh_view_panzoom2d`;\
mapkey(continued) ~ Update `panzm` `panzoomPH.ZoomSpinBox`0.300000 ;~ Activate `panzm` `OkPB`;
I also limit my overhead by customizing menus to make sure that all the icons I use fit in one row.
Don’t forget that additional vertical space gets added to your net working height since the overhead (icons and text) is mostly fixed. My portable has an overhead of about 200 pixels (Snagit capture image net size). So, the extra 150 pixels in a 24″ display adds about 18% to your useable drawing height, and a 30″ display would add 450 or almost 65%. Let’s see – 4px*34in/1400px = .1in? This implies that almost any reasonable text size should display in an E-size drawing without “greeking”. Is that worth an extra 15¢ an hour for the next three years? Should be!