Eric (and all),
I think you have put your finger on the root of the problem.
Fonts are in integer point sizes, and as they get apparently
smaller with layout scale they get harder for the math to grip.
And note that you can have a font point size of 9 at 1" = 200
mi, but at 1" = 400 mi scale you can't have it at 4.5 points;
it rounds up to 5. Then scale it back up to 1"=200mi and
everything is fubar.
The technique mentioned by several people here over the years
(the one that uses the NamedView tool in which you work at the
layout frame's scale in the mapper) works quite well for a
reliable WYSIWYG layout. And if you save workspaces at the
printing scale with layout window maximized, you don't get that
"string creep" that ruins all your nicely and laboriously placed
highway-shield numbers. But now that you mentioned how this
works, I see why that "save workspaces maximized" superstition
works; it's merely saving text at a size that can be re-rendered
reliably. Now I also know that it's not necessary to turn three
times widdershins to appease the Evil Prince of Bad Plots before
saving a workspace. But that wierd thing y'all do with saving
Custom labels by RowId in workspaces has got to go--it's a nasty
accident waiting to happen to some poor soul some Friday afternoon.
I think we've got the two basic kinds of labels now--those that
scale up and down with map scale (text objects) and those that
stay at the user-defined scale (auto- and custom labels), but
there's still a problem resolving how we specify the former in
MapBasic. With no GetTextExtents() function one is at a loss to
calculate the four corners of a text string. And worse, without
this, rotated strings are real piece of work! Plus the font
returned by ObjectInfo() does not even give me a font size to
play with! Ack! Thp!!! (sorry... as a developer I just HAD to
get that in!)
You're probably right about users not understanding how dynamic
labels work too. I see this all the time in the field. It's made
worse by users not understanding map scales and the scale
relationships of map windows to layout frames. They know what
they want, and MapInfo does provide the tools to do the job, but
if they don't recognize the tools, they can't do the job. What I
mean is that the tools have to be even simpler and obvious. It's
the developer's job to make hard things easy, not to educate the
user to understand the problem (that's Documentation's job
{muhaha!}).
Users see their real maps on the layout, not really the map
window. Print is the product for many people. That's where the
final graphic edits need to be, and these also need to be
reflected back to the map and to the database in some cases. The
backward propogation should probably be user controlled too. Some
people make a map, and then as far as the data is concerned that
"map" might as well be carved in stone (or silicon at least).
That map may be printed again and again, but it is not intended
to reflect the current state of the data. There are plenty of
very legitimate reasons for freezing maps (legal ones leap to
mind). But there are also good (and different) reasons for
maintaining a live link between plots and data. However, I think
the important thing should be that crossing into the layout space
signifies something very different in the user's mind, and the
software should keep up.
What the user expects when he or she moves a label has got to be
reflected exactly in the final print. Reasons that have to do
with precision and NP-hard problems are not acceptable. Nobody
(unfortunately) gives a ball of swamp emanations about the
software engineering miracles they don't even notice when their
map looks like soggy garbage, their boss flips out, their
company's stock tanks, and the hapless mapmaker is tossed out
into the cold, cruel snow. Even if one of the reasons for failure
is that they are just about as dense as a black hole on the
subject of map scales.
At the point the map moves from map to layout, it is no longer
geography--it's artwork, and the user expects a WYSIWYG interface
or he screams, cries, chews the rug and probably looks for
puppies to kick (artists can be touchy).
MapInfo has long left out the "finishing" tools to mapmaking, and
it's time this gets considered. All of today's desktop mapping
looks like cartoons... But even Saturday morning cartoons look
better now! The power is there in the PC; let's use it. Today's
PC Clamdippe 9000 chips can blow the crystal lattice off
yesterday's Motorola 68000's, but old Macs still rule in the
desktop graphics world (egad!). Why is a modern GIS program still
cloying to what's basically a 1980's EGA graphics paradigm?
Someday I hope to hear, "Yeah, maybe A**V***'s cheaper, but
MapInfo makes better-looking maps than anybody else, and we need
that edge in our business."
Don't believe in easy goals. Aim higher and you might be
surprised at what you can hit.
(and thanks for explaining the problem... candor is very much
appreciated. Means people are thinking about the fix.)
- Bill Thoen
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
