v.1.9 fails to honour first baseline in grid

[beast]

macOS High Sierra on MacBook Pro (Retina, 15-inch, Early 2013).

Have a document well over 100 pages that displays fine in 1.8.3 but not in 1.9. (Good job I kept the old version and only opened a copy in the new one.)

The problem is that no use is now made of the first line in the baseline grid.  This is set to 11pt first line then every 14pt from Top Margin of Master Page applied.  Font is 10pt on 14pt leading.

Have tried adding the same grid to the frame and reducing leading thru to 0. No joy.  Only thing that worked (p.1 (LHS) of attached; RHS shows problem) was using a larger frame to accommodate a whole 14pt. If I now have to do that to all relevant masters, 1) that's a lot of work, 2) what then is the point in the option to set the offset to the first line.

If you're going to change how something as basic as the Baseline Grid works in a minor upgrade then you should expect many people to see their documents severely disrupted, and for them to start yelling. Yell!

Please restore BG function to what it was…

Misalignment.afpub Misalignment.pdf

[thomaso]

I experience a few unexpected occurrences with your afpub (and/but don't have v183 installed for comparison). Also I wonder if in v190 possibly a former issue got fixed, e.g. regarding space before/after or text flow options (like "keep together" et al.), which you might have managed to workaround in your 183 .afpub and may occur now as a faulty behavior.

But first of all to me it seems you handle the baseline grid options in a sub-optimal way:
1. You haven't applied it to your document but to the body/story text frames instead. (in my opinion the frame based grid is meant as override/exception only, e.g. image caption text different to body text baselines)
2. There you have set a starting distance > 0 (which appears odd to me in combination with 1.)

I experience possible alternatives to fix your issue, either/or…
a. Set the frame baseline grid start to 0 (instead currently 11).
b. Change the baseline grid from frame related to document related.

Unfortunately some UI issues / bugs may confuse additionally:
1. It doesn't display an activated master page frame related baseline grid in the Text Frame options if its frames get selected on a documents page.
2. THOUGH/BUT I am allowed to tick the "Ignore Baseline Grid" for such a frame in the Text Frame Panel and/but without effect. (<– not demonstrated in the video below) / (I would expect this option greyed out instead for master page text frames unless in detached mode).
3. After altering the baseline grid from frame to doc related I am not allowed to select the last text line on page 3.
4. There is an issue in your test .afpub as a leftover of deleted pages: a pinned text frame (image caption) + its image (reported with quite weird placed DPI)
5. The known issue of "jumping" layout items as soon "Edit Detached" gets activated. (what if the orange bar gets placed at the window's bottom instead?)

[beast]

Many thanks Thomaso.

I'm not aware of any text flow options which might cause a shift down a line, which is apparent throughout the entire (100+ page) document.  There are many occurrences where there is no possibility of widow/orphan lines.  There is no space before/after in use on the main body paragraph, in use throughout.

The document I posted is a sample copy only. The original had baseline applied to the document. I merely applied to text frames (in Master Pages) to see if it made a difference.  It didn't.

The 'start' attribute I have assumed is the drop to the first baseline. This is how it was treated in v1.8.3, which was quite happy to populate it as long as the drop was ≥ font size. (As I recall, this is how it works in ID.) It appears v1.9.0 no longer interprets it this way. It seems to want 'complete' lines separated by at least the leading and refuses to use the first line at all.  If this was the original intention then the change was always going to upset existing documents.

Am not surprised about issues arising from deleted pages. These were many and often had images pinned.

Am unaware of any "orange bar" or mobile layout. Have had no problems with "Edit Detached".

It's starting to look like I have a major edit to perform…

[thomaso]

Sorry for possible confusion, some of my thoughts above are rather meant to the Serif team. – This is one of them: Here for the applied text style name the UI reports conflicting, unclear info (in the Text Style panel exactly 1 style is highlighted, though the text selection includes 2 styles), and for the "space before" it gives a rather wrong impression with this text selection (incorrect for the selected second line with a different text style applied).

28 minutes ago, beast said:

 There is no space before/after in use on the main body paragraph, in use throughout.

32 minutes ago, beast said:

The original had baseline applied to the document. I merely applied to text frames (in Master Pages) to see if it made a difference.  It didn't.

Do you mean none of the two possible fixes I used above successfully don't work for you?
In none of your documents, neither in the slimmed .afpub nor the complete document?
Don't these 2 changes change anything at all to you?

35 minutes ago, beast said:

Am unaware of any "orange bar" or mobile layout. Have had no problems with "Edit Detached".

How did you increase the height of the text frame on the left page 2 (#1) without detaching its master layer on this page?
Don't you get the layout shift/offset when you choose "Edit Detached" for the master layer on page 2/3?
(However, it's rather a visual UI glitch, not related to your baseline issue.)

[beast]

Neither of your suggestions works for me. Have already tried using the document baseline grid (which is what I have always used in the main document) – no change. Setting the 'start' offset to 0 defeats my purpose and leads to the text sitting too low. My original start offset of 11pt worked fine in v1.8.3 – the first line was populated. Making it 0 requires the change I made to the LHS – growing the text frame upwards by 3pt. This means it overflows the page margin by that amount.  I can do this for the master page and then reapply it to the entire document but this means significant work …and it's a bodge.

I made the change to the LHS by detaching its master. It's a small bodge.

I do not notice any shift when choosing "Edit Detached".

I believe that the first baseline, after the 'start' offset, should populate with text provided the font size is less, as it did in v1.8.3. I think the behaviour of v.1.9, where it begins populating a line only when the leading can fit, is wrong. This needs fixing.

Thanks again for your time.

 

[thomaso]

What is "LHS" ?

What do you get when opening the attached .afpub?   Misalignment_tho.afpub
Changes: a) unticked baseline grid for the two frames on the master + b) for the frame on pg 2. + c) reset its frame height + d) activated the document baseline grid.
The empty last line on the left page is according to the set flow options. The result looks like this:

[beast]

LHS = Left-Hand Side.

The single difference between your file and my original is that you've set the document grid to offset from the Top of Page whereas mine is set from Top Margin.

I am grateful for a very useful workaround, which saves me considerable time, but it still leaves us with what I believe is an error in Publisher v.1.9.  It should work fine with an offset between the font size and the leading (flowing text onto the first baseline). If I later choose to change the page size, I would have to also change the grid, which should be unnecessary and defeats the logical model of the document.  For this reason, it should work fine as well using the frame grid. It doesn't.

Furthermore, it is unacceptable to change the semantics of the grid in an 'upgrade' without any announcement. (This is exactly why I avoid 'upgrades' like the plague they are. They break things.)

Dear Affinity crew, please fix this. It's wrong as it is.

Many thanks again for your time thomaso and kind help.

[thomaso]

I agree, an issue like the unwanted empty 1st line should not happen at all, so, yes, it is something to repair by the developers.
I was/am just curious to detect what exactly is causing the issue (maybe with the selfish hope to speed up a fix by Serif)

I am slightly confused by your feedback. You said "Neither of your suggestions works for me." which sounds as if you still don't get rid of the empty first line with any of my workflows. But them you say…

35 minutes ago, beast said:

The single difference between your file and my original is that you've set the document grid to offset from the Top of Page whereas mine is set from Top Margin.

… which sounds you did get rid of the empty line successfully, though with another setting than me.
Currently I can't even cause the empty 1st line when I switch in my .afpub the grid from page to margin relation.
(though, in this sample, I obviously can't achieve the exact same starting position with the two grid bases):

[loukash]

5 hours ago, thomaso said:

Also I wonder if in v190 possibly a former issue got fixed, e.g. regarding space before/after or text flow options (like "keep together" et al.)

There are other – new – issues:

(Ignore the rest of the thread which is slightly off topic and not necessarily relate dto my bug report…)

[beast]

Neither of your suggestions works for me. Have already tried using the document baseline grid (which is what I have always used in the main document) – no change. Setting the 'start' offset to 0 defeats my purpose and leads to the text sitting too low. My original start offset of 11pt worked fine in v1.8.3 – the first line was populated. Making it 0 requires the change I made to the LHS – growing the text frame upwards by 3pt. This means it overflows the page margin by that amount.  I can do this for the master page and then reapply it to the entire document but this means significant work …and it's a bodge.

I made the change to the LHS by detaching its master. It's a small bodge.

I do not notice any shift when choosing "Edit Detached".

I believe that the first baseline, after the 'start' offset, should populate with text provided the font size is less, as it did in v1.8.3. I think the behaviour of v.1.9, where it begins populating a line only when the leading can fit, is wrong. This needs fixing.

Thanks again for your time.

 

[beast]

Thomaso: I can indeed resolve the issue by starting the grid at Top of Page.  It returns when I switch to Top Margin.

Loukash : Many thanks. Will investigate!

[beast]

Loukash nailed it!

I can keep a document (or frame) baseline grid offset between font size and leading from Top Margin, as in my original document (and sample). All I have to do is set Frame Minimum Offset to match that value and hey presto, top line is populated. Daft, but works!

This offers me a simple workaround, though the bug in v.1.9 remains.

Many thanks for help.

[Old Bruce]

I may be missing something here but I have to ask: Why do you not have no offsets applied to the text frame and just start it at the appropriate height on the master page? ie11 points lower down? 

[thomaso]

I have a similar question like Bruce: Why do you work at all with the baseline grid if you don't want it for the entire layout page but use it only within the main story frames – instead of setting the line spacing in the text styles as wanted?

p.s.: Just in case (though baseline grid overrides this): With APub v.1.9.0 comes a new text frame option for the position of the first line: The "Initial advance"…

  > 

[loukash]

6 minutes ago, thomaso said:

Why do you work at all with the baseline grid if you don't want it for the entire layout page but use it only within the main story frames – instead of setting the line spacing in the text styles as wanted?

I don't know what exactly @beast wants to achieve, but… Why not? What do we know about what else they have in mind with their layout? The app should simply follow orders.

In any case, the baseline grid implemetation and behavior consistency in APu still leaves a lot to be desired, that's for sure. But perhaps it's just me and my "high expectations" after relying on PageMaker's, Xpress's and InDesign's baseline grids for the past 30 years…

Just now, thomaso said:

baseline grid overrides this

In theory: yes.
In practice: not really.
The orange grid is where this paragraph style should start, but does not. And that's a bug, not a feature:

[thomaso]

35 minutes ago, loukash said:

The app should simply follow orders.

Agreed, as I did before already. Yes, there is a first line bug.

My concern was rather – knowing only the 3 sample pages of @beast – that this bug can be avoided/circumvented sort of easily.

For your example you could use the "Minimum" option of "Vertical Position", where grid start and 1st line position may even differ. e.g.:

[loukash]

1 minute ago, thomaso said:

For your example you could use the "Minimum" option of "Vertical Position"

… and that's exactly what @beast eventually did:

7 hours ago, beast said:

All I have to do is set Frame Minimum Offset to match that value

 

[thomaso]

Yes. Various ways to Rome. Alternatively you can set the top offset of 70 as frame "Inset" – instead of as "Vertical Position" (as in the sample above):

[loukash]

55 minutes ago, thomaso said:

Alternatively you can set the top offset of 70 as frame "Inset"

Yes, if you don't want anything above the main text.

But the point of having a reliable baseline grid start position is that you can do pretty neat tricks with it, e.g. a headline span (!) at the top with all text still running linear in one single frame, fully editable. Here the exact start position only works because of Flow Options > Keep Paragraph Together as a compromise workaround:

The right alignment of the headline as well as the drop cap position needs to be tweaked individually based on the length and size respectively, but other than that it's all based on text style rules. Fun stuff. Some of these tricks like text running outside the frame aren't even possible with InDesign CS5.5 – don't know about the CC versions though.

Edited February 15, 2021 by loukash
terminology

[thomaso]

Even there you wouldn't need the baseline grid or its shifted start – alternatively you can achieve the vertical offset of the body text with a "Space After" for the headline.
It seems to be a matter of individual habits / taste, I prefer to define as many properties as possible in text styles, using frame offset options only for exceptions (e.g. when they should have a border or fill color). This way I don't need baseline grids usually, though they may help during layout process when trying various font alternatives.

[loukash]

1 hour ago, thomaso said:

you can achieve the vertical offset of the body text with a "Space After" for the headline

Not if you want to have a fake span column.
See forum.affinity.serif.com/index.php?/topic/64963-span-columns/&do=findComment&comment=733694 ff. (and also the earlier posts)

But even in my previous example, Break Before Paragraph Only At Column Top in addition to the Keep Paragraph Together attribute was necessary to work around the grid start position bug.

2 hours ago, thomaso said:

I prefer to define as many properties as possible in text styles, using frame offset options only for exceptions

Me too.
Back in the day, (re)creating paragraph decorations – which the original designer had always positioned manually as plain lines and rectangles – as inline text styles in XPress 4 was pretty tricky to begin with. But then, laying out each brochure with a few shortcuts became so much faster…

And then, CS5… span columns… oh well.