Dear Bill, and list,
I completely agree to your comments about how much MapInfo neglected the
tools to make useful, presentable paper plots of our maps. Since the upgrade
to 32-bit MapInfo (i.e. Version 4) I haven't seen any major improvements on
this side.
Even ArcView (whose user interface I really do not like) seems to provide
much more tools in this respect (at least since the last upgrade to V 3.1):
Neatlines, grids, dynamic scalebars and apparently an intelligent autolabel
function. It seems that their layout is more WYSIWYG. But since I don not
use it much I can't say whether all this works. However, it shows that MIs
main competitor has made improvements in this field, that means the customer
base wants it, so it must give enough revenue in upgrades or new customers
to justify an overhaul in these fields.
On the other hand it is really good to see, how some people at MapInfo watch
this list and provide a lot of useful solutions. I haven't seen anything
comparable at ArcView-L. So thanks to TechSupport.
But let us hope that this interest also results in improvements in the
topics we demand most (but what is most, how does the comments of this list
really reflect the opinions / needs of MapInfo's money-bringing clients) ?
Thomas G�lden
Diplom-Geologe
Email (privat): [EMAIL PROTECTED]
Email (dienstl.): [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill Thoen
Sent: Mittwoch, 10. Februar 1999 05:12
To: [EMAIL PROTECTED]
Subject: Re: MI Labels not plotted in right place!!!!
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]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
