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.

There are many occasions when one needs to introduce a multicolumn segment within text, or indeed a full blown table. This is currently (1.7.3) very badly supported. After pasting a table into the text, I'm left with no way to flow or wrap text around it, nor can I assign space above or below it. Am left with a dead paragraph. This is basic guys, and needs fixing with a high priority.

PS Away for a week in Italy, and cannot respond until I return.

1. I was editing in detached mode. View/Text Flow is not very intuitive. A View/Text Frames option would be better, or perhaps making them visible following View/Guides. 2. Studio panels docked, where they obscure 'Finished.' 3. Noted that bug already acknowledged. 4. By clean I mean sharply defined plus quality of appearance generally. Something ain't quite right. Compare with InDesign, like for like, and I think you'd agree. 5. Thanks, though I do find the Transform panel a little odd sometimes. Looking in a 'Transform' panel for the exact size of a frame, for example, is not what I'd expect. 6. Thanks. Will seek out those discussions.

Aff. Publisher 1.7.2, MacOS 10.13.6 (High Sierra) Not really bugs but annoying deficiencies in user interface : 1. I can find no way to keep all frame boundaries visible, making it impossible to butt one against another. (No snap on here.) 2. After detaching a master page (via ctrl-click menu), the 'Finish' button is obscured by the studio. 3. I like the listing of matches following Find but when you highlight one in that list, it really should be highly in the text also. In fact, the first instance ought to be highlit there anyway. 4. The rendering of a page still doesn't look anything like as clean as it does in InDesign, somehow. 5. I can find no way to directly kill an instance of hyphenation. 6. InDesign's 'Composer' does a better job of formatting a paragraph. Not sure exactly what it does, but it seems to juggle tracking as it lays out a paragraph, and perhaps hyphenation. I can only match it in Publisher by applying different tracking to individual sentences and words. I do NOT mean to be negative here, just helping with aspiration. Over all, I'm happy with the job Publisher does and am moving over to it (despite CS5.5 working acceptably well on High Sierra). I don't feel the need to catalogue the things it does better than InDesign. The recent MacFormat review said enough. Well done guys, but please keep at it (especially Footnotes and IDML import).

I need to pick up the font itself and left Font Size as No Change. It should then surely leave it unchanged, according to the context (inline text). This was never a problem with InDesign. Will remove Based On preference.

No, I do not assign a paragraph style to part of one only. I assign a character style to part of a paragraph, already subject to a paragraph style. The second time I apply that character style, it retains the font size of the paragraph in the first application. See the example attached. Test.afpub

MacOS 10.13.6, AffPub 1.7.1 I create a text style that adds underline, with all else "No Change". When I apply it to part of a paragraph, the character size from the previous application is adopted, not the size called for by the paragraph style applied. (Easy to demonstrate.) Would love to have "nested styles" from InDesign – makes stylish headings effortless. I'd place this second priority after adding automation supporting footnotes.

Many thanks! I did not delete it, but simply shifted the image then regrouped text and picture frames and applied text wrap. All went fine. However, there is clearly a bug lurking in here, associated with layering and locking.

Am unable to unlock two frames which somehow locked themselves. Cannot reproduce so far in new document. Here's how I got there : Document with text auto flowed through ~dozen pages, based on same master page. Created picture frame and text frame for caption. Placed image in picture frame, selecting no scaling. Grouped the two and set block to wrap text around one side. Image needed an offset to appear centrally aligned, so ungrouped, selected image in Layers and shifted it left a little. I then find both frames locked. Can unlock image but not its frame. Cannot unlock (tried menu option and lock/unlock icon in Layers panel). Without being able to unlock the two frames, I cannot even delete 'em and start again. Very grateful for any suggestions. Apologies if I've missed something. (Have trudged through bug reports.) MacOS 10.13.6 on MacBook Pro (late 2013) Programming_Period.afpub

Have managed to apply the corrected master page, though with some considerable difficulty. Had to Apply Master to affected publication pages, which disconnected text flow. Had to reflow it. Still think that any change to a master page should automatically appear on all publication pages using it, and that there should be only one baseline grid per document, as in InDesign, though can see utility of using a different one per spread or section. Should be an attribute of just one of these at a time IMHO. Thanks again for the help.