9.0.177.4

manifold-9.0.177.4.zip

SHA256: 6fc548ea705b7e047bfa0e1749f1e9cdfdd133e694db34e04fbfc70ce834a51e

manifold-viewer-9.0.177.4.zip

SHA256: db91d20587d79c952899fadf2e686a8059ecd1b826d39a2c86e9f7627e187e76

sql4arc-9.0.177.4.zip

SHA256: fb3b585296de0266934a96b79e42a2103ecc6fcf3312937ccfb80c48bb1ebf26

Changes

Sample positions / shapes for layout frames are localized.

There is a new -export:xxx command for the Commander (MANIFOLDCMD). The command exports the specified component in the input file to the output file. The specified component can be in a nested data source. The input file is always opened in read-only mode, the value of the -open:xxx option is ignored.

(Example: manifoldcmd "c:\world.map" -export:"Main Map" -out:"c:\world_map.gdb")

(Fix) Writing MIF removes unsupported characters from field names.

Reading MIF allows duplicate field names and makes them unique. (Such names sometimes appear due to encoding issues.)

(Fix) Clicking a label no longer sometimes picks a wrong label or does nothing.

Editing a text style allows specifying how many labels to place onto a line:

• one per branch (default) - the system will try to place a single label for each visible branch of each record (note that this applies to visible branches = visible parts of branches, not physical branches; for example, if a physical branch goes offscreen and returns back, it will produce multiple visible parts and the system will try to put a label onto each such part),
• one per record - the system will try to place a single label for each record,
• repeat - the system will try to place as many labels as will fit into each visible branch of each record with the specified spacing between labels on the same branch, the spacing can be specified either in absolute units (eg, 40 = 40 points) or in relative units (eg, 800%, the default = 8x the font size).

Editing a text style allows specifying how to place labels onto a line:

• curve (default) - the system will bend label text following the shape of the line,
• straight - the system will place a label without any bends in the direction of the line in the center of the text,
• straight horizontal - the system will place a label without any bends in the horizontal direction,
• straight perpendicular - the system will place a label without any bends in the direction perpendicular to that of the line in the center of the text.

Placing a label onto a line preprocesses line metric to make it smoother.

Placing a label onto a line in one per branch / one per record modes prefers positions near the visual center of the line.

Placing a label onto a line produces a tighter and more accurate overlap shape. (This improves the accuracy of clicking into labels. This also allows showing more labels in that labels that are close to each other start conflicting later than they were with former less accurate overlap shapes.)

Editing a text style allows specifying overlap spacing, which controls how close individual labels can be to each other. The default is 1 pt.

Editing a text style allows specifying bend spacing to apply to labels following lines. With bend spacing, placing text onto a line adds small amounts of space between individual letters at each bend to improve readability. The amount of added space depends on the bend angle, sharper turns get more space. Bend spacing defines the maximum amount of space to add to a single bend. The default is 50% = add up to half of the font size at each bend.

End of list.

Great way to start of Monday morning. :-) Really looking forward to trying this out. Looks like the curvy line readability issue has been solved. Thanks!

You mentioned once the challenge of conflicting labels and multi-threaded rendering. In the meantime, in order to deal with conflicting labels from various layers, I wonder if it would be worthwhile to write a query that pulls in labels from various layers and orders them for priority of display? Might this be a way to either tackle the issue until a solution is found or perhaps a way for Mfd to solve it by creating a dialogue that makes that process user friendly?

I think it would be ideal for Mfd labeling engine to allow the user to assign priorities amongst labels, as well as their styles. Things like label big cities first, make long labels multi-line, label along straight portions of line first, etc. Would a label dialogue for each map make more sense than styling and ordering individual layers?

We'll allow specifying that labels from multiple layers should not overlap.

Assigning priorities to individual labels is a different feature. We agree it is useful. It can be applied to drawing objects as well. Maybe in the future we will implement it, too. Until then, let's prioritize using different layers.

Okay. I see that the conflicting object labels within a single layer results in no labels within the conflict area. The notion above of writing a query to avoid conflicts wouldn't help with that. Hope that can get improved as well, so more labels show up.

FWIW, I'm seeing line labels that could use some fine tuning for readability. Either due to a gap placed where it shouldn't or where it could use a gap. Seems like adjustment of the gap size and more smoothing of the line metric would help.

We need example data to see what should be tuned and how. Eg, a labels component, a location component, and a screenshot of what it looks like on your system with problematic places indicated in some way. We have several tens of such examples ourselves which we think could look better, but maybe your examples are different.

You can adjust the amount of additional space added at bends by changing bend spacing. Also, if label text is short, just use one of the straight modes.

Here's a map file and two screenshots from zooming to the location component on my laptop. First screenshot uses the default of 60 for the bend parameter. The second screenshot uses 20 for bend. The blue marks show where the label letters overlap and red marks show where the gap looks awkward. Seems like there should be some sort of way to force a certain distance between letters. Easier said then done, I'm sure.

The other issue is just the lack of labels in conflict areas. One or more of the labels should show up. Probably the longest line should get labeled first.

Attachments:
Capture.PNG
Capture2.PNG
t.mxb

Thanks, that helps. We will check all of these cases.

I have to say though, we are happy to see that these cases look relatively benign (no crazy surprises). I mean, sure, there are places where spacing looks too wide or too tight, and maybe we will find a way to improve it. But at least half of the cases look pretty close to what the system can achieve just rendering text normally, in a straight line. Take a look at the screen from Windows Explorer that shows the name of the MXB file:

Note that the space between 'm' and 'x' is shorter than the space between 'x' and 'b'. The scale of the difference appears to be similar to that in some of the cases on the screens. So in those cases we already appear to be pretty close to what could be achieved in general.

Attachments:
uneven-spacing.png

Got a little carried away with my marker. :-)

It is looking much much better. As a goal readability is more important than following the line. The worst offenders are where a label gets drawn relatively straight, but the system puts in a sizeable gap. Especially where you might think it is supposed to be there, like within a bunch of numbers.

Attachments:
Capture.PNG

OK, good news.

We already identified one issue with hinting earlier today (glyphs were being hinted based on their left side instead of their centers, that's kind of wrong). So I ran your data on the build with the fix. The fix improved several cases immediately.

But what's more, you changed the maximum allowed bend angle from the default 60 degrees to just 20 degrees yet kept the bend spacing at the default 50%. Bend spacing defines how much spacing is going to be given to the maximum bend angle, so a relatively tame turn of 20 degrees already adds a space as wide as 50% of font height, that's pretty big. If you want to decrease the maximum allowed bend, decrease bend spacing as well. Changing bend spacing from the default 50% to 10% improved the picture significantly. (Frankly, if the maximum allowed bend is as tame as 20%, you might not need bend spacing at all. There will probably be some overlaps, yeah, but rarely and their size will be small, the text will stay readable.)

Take a look at the three screens: *before is the original in 177.4 (no fix for hinting), *after is the same data in 177.5 (not yet released, with the fix for hinting) and with the bend spacing changed to 10%, *after-marked is the same as *after but with the numerous visible improvements marked in red and a single remaining questionable case marked in blue. Now, regarding that single remaining questionable case, we will investigate further, but I guess that's just how the font is. Removing bend spacing (setting it to 0) removes the gap between 1 and 1 there, but in two other places the letters nearly start touching at bends, to my eye bend spacing of 10% looks better.

Attachments:
label-hints-after-marked.png
label-hints-after.png
label-hints-before.png

Super. Glad to hear you found the hint issue. Looking really good!

Indeed that was a poor parameter setup I used, but it would be best if we didn't have to worry about whether our settings make labels unreadable/gappy. Especially with web mapping since labels dynamically change. I'm thinking the settings should just vary the labeling between easy to read (more straight, less labels) and harder to read (curvy, more labels).

As Mfd works on label conflict, I thought it might be helpful to hear users priorities on how to modify labels to get more placed. Here's my attempt at a preference order: 1) placing labels closer together, 2) rotating labels, 3) shrinking label font, 4) stacking labels (without preloading a carriage return in the label), 5) leader lines, and 6) spreading letters or words of a label out. There also needs to be a a manual way to adjust labels without harming automatically placed labels.

Good labeling is great for static maps of course, but it allows for quick understanding of mobile/web maps as well. Not expecting this level of sophistication, but Maptext.com has made a business out of it.

Nice list, thanks. Let me ask a couple of things:

1 - placing labels closer together - do you want labels to overlap? As in, allow overlap spacing be negative? Or are there cases where labels can go closer together, but we do not appear to place them close (best assessed by slowly zooming out until two labels collide and one of them disappears, then noting how far the labels were just before one disappeared)? If it is the latter, we'd be interested in seeing examples.

2 - rotating labels - that's for labels bound to points, correct? Do you want a fixed setting, eg, "rotate 30 degrees"? Or do you want the system to try rotating a label if a label cannot be displayed horizontally?

3 - shrinking label font - automatically, if the label cannot be displayed with the original font? In general, this seems dangerous (we don't want to create a mish-mash of varying font sizes and it is hard to gauge when it would be fine to decrease label text without harming overall readability of the screen).

4 - stacking labels - splitting label text into multiple lines? Would specifying maximum width work? Also, that's for labels bound to points, not for labels following lines, correct?

5 - leader lines - fine.

6 - spreading letters or words of a label out - that's for labels following lines, right? Fixed character spacing + fixed word spacing + bend spacing that we have now.

Regarding a manual way to adjust labels without harming automatically placed labels - we have style overrides, use those. (That's when each record has a text field with the style, if it is NULL, the system uses the default style, otherwise it uses the style in the record.)

1. I suppose someone may want maximum amount of labels despite readability issues. I'd be fine without it but sure add it with a note in the manual saying this may result in unreadable labels (no system governor for maintaining readability).

2. Rotating is good for all geom types if it means more labels. Also, looks good with elongated polygons and long lines. Rather than a fixed amount, I'm thinking it should rotate the minimum amount to do the job.

3. Agree too many sizes would be bad. Perhaps let the user choose 3 or so okay sizes.

4. Yes multiple lines and I'm thinking for all geom types for the purpose of getting more labels. If a line can't get placed normally, then stacking it would be a good option. A max length would be good, but it would best if it split at smart locations in the label. Sparsely stacked labels add a touch of class even when they are not really needed.

6. Good for big polygons too, like a continent. That formula is good.

Regarding manual placement, I was thinking more like the user grabs some handle on a label and moves it to improve the label placement. Love style overrides. Perhaps there should be another equivalent field that holds labeling style info?

Also nice if there was some way to access info on labels that weren't placed, so the user can decide if manual placement of some of these labels is justified. Maybe that could get denoted in another field added to the table. It would be nice to see the label handles of those that don't get placed and allow the user to move them in order to get the label placed.

Images below are from Maptext's website.

Attachments:
image_2022-08-04_101813382.png
image_2022-08-04_102145477.png

Too add to the complication (ugh), when possible, it's best to avoid layer vector lines and points when placing labels. Don't mean to be a pain in the rear, but thought it worth mentioning.

Are you sure you would want that Mike?

How frustrating it would be if Manifold “just did it” for us, and we didn’t always like the result.

The labelling engine has access to all the data, of course, but it doesn’t know it the way a human can—and can’t even see the results of its efforts.

Giving up the ability to tune label placement would be a retrograde step I think.

For one thing, you and adamw couldn’t have had the helpful conversation you have just had in this thread.

The point about web mapping seems well made (and probably applies similarly to server usage). Perhaps there is a need for a higher degree of automation (more agressive heuristics) in that context.

But I would hope not at the expense of control when we need it.

We could define bend spacing not as "the amount of space given to the maximum bend angle specified by the user", but, say, as "the amount of space given to the 90 degree bend angle". That way, changing maximum bend wouldn't need a corresponding change to bend spacing. The problem is, the second rule is harder to remember than the first one, it contains a magic number. And there's no good angle to pick for that magic number. 180 doesn't make sense, bends like that don't occur, if we pick 180, the number specified for bend spacing won't be reached anywhere. 90 could easily be too small to someone's taste. So we went with the first rule.

In any case, whatever we do won't be at the cost of the ability to fine-tune things. We think the best magic is not in the form of providing less choices, but rather in the form of providing many choices but also having reasonable defaults and / or being able to put some of the choices to "auto" with some smarts behind. That way, if you don't want to bother fine-tuning anything, you can. But if you want to fine-tune, you can do that as well.

Agree with you both on having manual control, but if possible it would be nice to have some sort of governor to avoid bad looking labels. We can't visually inspect all the possible labeling scenarios in web maps.

My current workaround for stream wiggle is to run their [Geom] field through the Generalize routine, I took the query and created an expression field using that bit of sql. This helps straighten out the mountain streams. Basing the label on that calculated field eased the previous line labels parameters re: bend, offset. looking at the stream wiggle in your example, I think you might want to test this with the newer build.

Meandering streams are definitely a good test case. Fortunately, the need to smooth lines before labeling should be a thing of the past in 9. Seems to be true with my data so far.

I feel confident that a generalizing tool will be rolled into 9. Until then my callout and stream workaround will suffice.

Just some thoughts that might be helpful.

Perhaps it would be good to add tabs to map components for labels, layer zoom ranges (future), and dynamic legends (future). These could open up a dialogue window that allows setting these up in one window for all layers rather than doing it within each layer. Faster to setup and you get to see the big picture and how they all interact. It might also avoid lots of label components cluttering up a map's layer pane.

Maybe layers should have a base style, but then within each map you can set a layer's style without having to create a new component. Changing a layer style doesn't automatically change it within other maps, but you could import a layer's style from other maps.

I am not sure I understand - the map window has tabs at the bottom that show layers and layer groups. Do you mean adding new tabs to these ones? Or do you mean adding new tabs to some pane, maybe?

We have zoom ranges, you can set them via the Layers pane. Including for multiple layers simultaneously.

Why would you want to alter the style of a layer in one map but not in others? Not saying this is never wanted, but why specifically do you want to do that in your case? Because maybe there is a better way to do what you are after (eg, some "auto" setting that adjusts to what happens in different maps).

Sorry for not being clear. I was thinking with a map component, under the Info pane there could be additional tabs next to the current "Component" tab.

Ah, forgot that zoom ranges has already been taken care of.

Changing a layer's style is often useful when changing the map background from an aerial photo, hillshade, topographic, or just blank. It might get complicated to have an "auto" setting but it sure would be nice if it could work, since users may want to switch the background often.