I'm working on labeling polygonal water features in Pro 3.1.4 and have been struggling with their labels. I'm trying to go for the "curved in polygon" placement with a horizontal position tried first. Depending on the scale and extent shown, though, the engine will sometimes fit the label horizontally within the polygon by compressing or outright removing the spaces between words:
If it can't fit the text without deleting the spaces, I'd rather it place the label somewhere else or curve the label. The next couple photos show slightly different extents/scales where it placed the label better:
This map'll be going online eventually so I don't want to see the spaces removed at any point as you pan or zoom around.
Here's a screengrab of my position settings:
Font width compression is disabled in the Fitting Strategy pane, but even if I enable it and set the lower limit to 100%, it still compresses the spaces the same. How can I fix this?
Solved! Go to Solution.
Well, that might indeed explain why I haven't seen this issue. Although I have used the "Spread letters up to a fixed limit" option in multiple label classes for years, I do not routinely use the option to spread words.
However, the removal of spaces in case of "Spread words" sounds like a bug needing reporting. It really doesn't make sense to remove spaces entirely, as it can heavily affect readability of the label.
In my experience though, just using "Spread letters" is enough, and will also give a convincing and cartographically nice larger gap between words, so maybe that is an option for you too, and just leave the "Spread words" setting at its default value.
I have extensively used the Maplex label engine with similar settings for waterbodies in various versions of Pro (1.0 to 3.2), but never saw the "disappearing spaces".
Looking through the Maplex settings, the only real option I see that might make this happen, is if you have the Position / Abbreviate option selected, and accidentally added a space to the string of characters in the box "Characters to remove first" under Truncation, which might not be immediately obvious. I am not even sure that box accepts spaces, I have never used this specific option.
Abbreviation strategies are disabled on this map, so it isn't related to that. However, I poked around a little more by reconstructing the label class and found that the disappearing spaces only happens when Position->Spread labels is set to something besides "Use default word spacing". Even if it's set to "Spread words up to a fixed limit" and that limit is set to 100%, the spaces will still be removed. So it seems like you can modify the maximum word spacing but not the minimum word spacing.
Well, that might indeed explain why I haven't seen this issue. Although I have used the "Spread letters up to a fixed limit" option in multiple label classes for years, I do not routinely use the option to spread words.
However, the removal of spaces in case of "Spread words" sounds like a bug needing reporting. It really doesn't make sense to remove spaces entirely, as it can heavily affect readability of the label.
In my experience though, just using "Spread letters" is enough, and will also give a convincing and cartographically nice larger gap between words, so maybe that is an option for you too, and just leave the "Spread words" setting at its default value.
Yeah, I've decided to just stick with keeping "Spread Words" off for the time being.
I have one more question for you, what are the settings for "Word spacing" and "Letter spacing" of the label class's Symbol?
On this help page:
You can see the text:
"These values become the minimum values when you use the Spread labels labeling option."
Is "Word spacing" perhaps accidentally set to 0%? It defaults to 100%.
Hi,
So what's happening here is you have the 'Try horizontal position first' checked so the label engine will prefer to use that horizontal position (with the spaces removed). The reason you're seeing the label placed curved and spread in the polygon at a different scale is because it can't fit the horizontal label in so is trying the next option (and spreading as far as it can up to your set limit).
I'd prefer the engine try the horizontal position first. What doesn't work for my needs is that it considers the space an optional part of the label when it isn't. If the engine isn't able to fit the label horizontally without deleting the space, it shouldn't use horizontal placement. I can't really imagine a scenario where this behavior would be desirable, and there's no method to toggle it, so I think it's either just an oversight or a bug.
@Crinoid wrote:If the engine isn't able to fit the label horizontally without deleting the space, it shouldn't use horizontal placement. I can't really imagine a scenario where this behavior would be desirable, and there's no method to toggle it, so I think it's either just an oversight or a bug.
Totally agree, this behavior doesn't make any sense from a cartographer's perspective. No real world cartographer would ever totally remove spaces between words making labels essentially illegible.
It is bit sad we need to explain basic cartographer's 101 to a company like ESRI...