Publisher for Windows 1.8.3: Unexpected baseline shift — but w.a.d.?

[MikeA]

("W.a.d." in subject-line stands for "working as designed".)

Before I call this a bug I'll post about it here — see if there's some "w.a.d." behavior I'm just not aware of.

The situation: a block of text entered in a font (from Google Fonts) called Cormorant Garamond Semibold. I decide to add a run-in subhead using a font named Mukta (also from Google Fonts). I decide later to move the run-in subhead to a different paragraph. So I highlight that text, and the spaceband (old typesetter term meaning a word space) that follows it, and press Control+X.

Immediately the baselines of all lines in the paragraph shift upward by a couple of points. I press Control+Z to undo the change. The baselines return to where they were before. I re-select the inline subhead, but this time I don't include the spaceband that follows it. Again I cut the text with Control+X. This time the baseline does not shift upward.

Next test: I select the run-in subhead and simply delete it, leaving the spaceband behind (it is now the first character in the paragraph). No baseline shift. Then I delete the spaceband. The baselines shift again.

Later, after making a few point-size changes to the run-in subhead, I can't replicate the unexpected baseline-shift behavior.

When it was happening, I checked the baseline offset value in the Character panel and it was the same for all text (it was the nominal point size value for the paragraph as a whole). Whatever the culprit might be, this kind of thing could play complete havoc with a publication's baseline grid and so: wotthehell might be going on here? Ring any bells?
 

[R C-R]

It would be easier to see what you are talking about if you added a small .afpub file that demonstrates the issue to this topic.

[MikeA]

56 minutes ago, R C-R said:

It would be easier to see what you are talking about if you added a small .afpub file that demonstrates the issue to this topic.

I could do that, as I did keep the document around for testing. Does Publisher have a way to bundle up the document plus the fonts it uses into either a single .zip file, or at least copy the whole business to a single directory? I would need to include the fonts. The .afpub file is fairly small. With the fonts included, the .zip archive wouldn't be so small.

[R C-R]

53 minutes ago, MikeA said:

Does Publisher have a way to bundle up the document plus the fonts it uses into either a single .zip file, or at least copy the whole business to a single directory?

There is a new Collect function in the Resource Manager but I do not think that includes collecting fonts into a single directory. However, as long as your demo file uses Google Fonts anyone can download for free that should not be a problem.

[MikeA]

I've put a .zip file (Odd-baseline-shift_Publisher1.8.3.zip) on Google drive, containing the .afpub where I saw the problem.

https://drive.google.com/open?id=1RNUrWti5S04BucMYzdgFbQG8QQfxKt7M

The .zip archive contains the .afpub file (Odd-baseline-shift.afpub). There's also a "readme-first.pdf" that explains the problem. The PDF file contains links to the necessary fonts on fonts.google.com. 

It's a peculiar business. The odd baseline shift occurs in just the one paragraph as far as I can tell. The PDF "readme" describes which paragraph to look for.

[lacerto]

(...(

[MikeA]

6 minutes ago, Lagarto said:

The mentioned space character has a character leading override of 16 pts which causes the current alignment. Once it is removed, paragraph based leading is used, causing the shift.

I'll be damned. I thought I'd checked for all that very carefully and it was, I guess, the one character whose leading override setting I didn't spot. Thanks for that.

All the more reason for me to dislike — the longer time goes on, the more intensely — the leading-override feature. Too many cooks and all that. Well, I don't know. Maybe these days leading override is just all the rage in publishing software. I could happily live without it.

Thanks.

[lacerto]

(...)

[MikeW]

6 minutes ago, Lagarto said:

... In QuarkXPress I am not sure if character based leading exists, at all, so if you have earlier done layout with QuarkXPress, you'd not be familiar with this kind of behavior.

Nope, Q doesn't have leading override as a character attribute. One would, if needed, use the Measurement Panel or shortcut to override leading. Using the equation example, the only way leading affects an inline equation in Q is if one is using percentage-based leading. If one is using discrete leading values, and if the equation collided with descenders from a preceding line, one would need to increase the leading via one of the aforementioned means.

Frankly I don't see the value of it as is in APub. (And especially agree concerning inadvertent changes re the mouse wheel.)

[MikeA]

6 minutes ago, MikeW said:

Frankly I don't see the value of it as is in APub. (And especially agree concerning inadvertent changes re the mouse wheel.)

If there were such a thing as a user option for...not to put too fine a point on it... "forever disable, ignore, shun, and rebuke-leading-override-in-the-name-of-all-that's-holy" I would gladly switch the feature off and leave it off. And yes, the possibility of making an accidental change to such a field via just the wrong spin of the mouse wheel at just the wrong time — it's just asking for trouble. Case in point: clearly I managed to change the leading override of that one space character without realizing I'd done it. So: my bad — and how easy it is to make such a mistake.

The latest revision of the raw converter Capture One implements mouse-wheelies this way:

Either
   Spin mouse wheel to move sliders, in which case:
   Use Alt+mouse-wheel-spin to scroll the tools panel.

Or
   Spin mouse wheel to scroll the tools panel, in which case:
   Use Alt+mouse-wheel-spin to move sliders.
   (Or: click within a slider's numeric-entry field and spin the mouse wheel sans modifier key—just like the old days.)

It took me a while to become accustomed to that; the old way was "mouse wheel spin = do all of the above" but I'm used to it now. More or less. At least it isn't as easy now to make inadvertent changes.

[Wosven]

Same here, I disable this if possible to only have the leading applied to the whole paragraph.

The mouse wheel wouldn't be a problem if the fields or panel where highlighted or get a colorfull border when they get the focus.
For now, I try to keep most of the options collapsed but the ones I'm working on in the panels, to avoid inavertently modifying options when scrolling.

 

[MikeA]

44 minutes ago, Wosven said:

The mouse wheel wouldn't be a problem if the fields or panel where highlighted or get a colorfull border when they get the focus.
For now, I try to keep most of the options collapsed but the ones I'm working on in the panels, to avoid inavertently modifying options when scrolling.

Having them "light up" on getting the focus is a nice idea. I imagine it would be a lot of work for the developers to add such a feature at this point in the program's development. I decided to put a few often-used tools into a single floating panel and keep it collapsed most of the time (character, paragraph, text styles, text frame, and transform). It seemed like a pretty good strategy until, kind of at random, the panel has begun vanishing without having been explicitly closed. I bring it back with Control+T for character attributes, then must add the other tools manually with several trips to View > Tools. Kind of irritating. But it's so random — when I run across it, it's just after I launch the program — that I can't imagine writing up a repro scenario. Thus — not much use as a bug report.

[lacerto]

(...)

[Wosven]

1 hour ago, MikeA said:

I imagine it would be a lot of work for the developers

I'm not sure, since it can be a general property for those fields, not needing to be set for each one, if I remember how Qt or other script interfaces work.

[MikeA]

It certainly wouldn't hurt if the sliders and/or data-entry fields could "glow" at least a wee bit when they receive the focus. Nothing radioactive-looking, of course.