beast

Many thanks for all responses. Have found that jogging the baseline separation and then returning it to where it was does indeed cure the problem.

After updating to Publisher 1.10.4 (from 1.9.1), I noticed that the drop cap height had increased by one line. Then I found it does this only with new material. Enclosed file shows same format applied to a paragraph on two distinct pages : first one, I get the 2-line drop I set; the second, I get three. Thought it might have to do with frame settings, given two different masters but then a rework of that first page, using the same master (or combination of two masters) again yielded a 3-line drop. It's possible I missed this in the previous version. The paragraph formatted correctly dates back a year or more. But cannot get this to work now. Would prefer not to have to work around. Humble apologies if I've done something stupid. MacOS High Sierra (10.13.6) on MacBook Pro (2013) Drop_cap.afpub

I agree wholeheartedly. UK English should mean the OED (the number or choice of volumes is irrelevant). At the very least, this should be an option, especially from a British company (of which we can otherwise be very proud).

Thank you for your help. Wrong is wrong and the 'ise' spellings are wrong. It should at least be possible to choose which to use from the top. If the underlying system gets it wrong, or provides no easy way to choose (remember, at least two hundred verbs plus the various tenses and associated nouns) then a publishing app must offer an alternative. I have already hit the 'Learn' button more often than I can count, and face the likelihood that I've missed a few, having been denied the benefit of automation. Despite being a former systems programmer, I have no intention of editing a hunspell library, which again exposes me to the risk of missing things. I disagree. To serve the publishing community, it is definitely incumbent on the producer of a publishing app to get the automation of spelling checks right. Sadly, I don't expect this to happen.

Using MacOS High Sierra, the only preference relevant is for Language and Region, where I have selected English (UK). There is a Dictionary app, but that is sitting exactly where Aff Pub is, and offers both spellings but with preference for 'ize'. It claims to use the "Oxford Dictionary of English" from OUP, which must surely equate with the OED. The MacOS spelling dictionary is not something easily messed with. (It reportedly uses a third party system with no simple replacement.) Apple are clearly not interested and have ignore a number of demands to fix this. As a result, I don't think it unreasonable that Affinity incorporate a spelling dictionary and perhaps offer a choice. It cannot be that difficult to simply refer to a chosen source. Control over the spelling dictionary employed is important for anyone publishing…, well anything really. Simply referring to the underlying system would be fine if both Mac and Windows offered reasonable control (i.e. choice of dictionary), but they don't.

MacBook Pro Retina 15" (early 2013), MacOS High Sierra 10.13.6 I suspect this issue predates v1.9.0. (Have no way to tell as no my documents won't even open in v1.8.3 after they've been save by v.1.9). According to my copy of the Oxford English Dictionary (Concise OED, 1992), the 'ize' have it. Words like 'recognize', 'initialize' and 'optimize' are not correctly spelt when ending in 'ise'. Why does AffPub, and even this website, try to insist that they are? I have set Preferences/Language to 'English' (not 'US English') and restarted both the app and the Mac. No joy. There is no alternative dictionary. I hope I can override the preflight complaints… From Wikipedia : "The Oxford University Press states that the belief that ‑ize is an exclusively North American variant is incorrect. The Oxford spelling affects about 200 verbs, and is favoured on etymological grounds, in that ‑ize corresponds more closely to the Greek root, ‑izo, of most ‑ize verbs. The suffix ‑ize has been in use in the UK since the 15th century, and is the spelling variation used in North American English." It goes on to blame the French for the more recent use of 'ise'. I do not plan to drop the 'u' in 'colour' any time soon (or use an 's' in 'defence') but there are times when our friends across the pond are right. We should harmonize (sic) where we can. AffPub should allow us the choice. At least allow both variants through preflight (as long as they're consistent). This is rather more important than it might seem.

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.

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!

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.

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.

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.

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…

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

When I started AffPub up today (by dragging and dropping my file onto the application icon), text was very badly rendered (see screenshot below). This has happened before but does NOT occur every time. For example, later in the day I restarted AffPub exactly the same way (though after earlier mods to the document (simply adding text) and the text rendering was fine. Performance prefs unchanged from default. Am using a MBP Retina 15" (early 2013, 2.4Ghz) with 8gb RAM, High Sierra and AffPub 1.7.3.

Many thanks. I will try pinning.