Jump to content

beast

Members
  • Content Count

    35
  • Joined

  • Last visited

Posts posted by beast

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

     

  6. 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.

  7. 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.

     

  8. 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…

  9. 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

  10. 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.

    459991606_AffPubcrappyrendering.thumb.jpeg.905c5a8738c0fb9a51977de400ac29e3.jpeg

  11. 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.

  12. 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).

  13. 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.

  14. 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

  15. 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.

  16. Ok, thanks. Now I have a different problem.

    On the publication page where the problem appeared, the text frame baseline grid sub-panel was inactive. So I looked on the Master Page concerned and found it active.  Turned it off. Things looking much better there.

    Problem now is that none of the publication pages have updated. They still show the text frame baseline grid. Do I have to delete them all and create new ones? Rather negates the whole point of master pages if so.

    I am also foxed as to why allow distinct baseline grid in any text frame when surely the whole point is to align text between frames.

    Programming_Period.afpub

  17. I have been attempting to reproduce InDesign typesetting prior to migration. Latest problem is with the baseline grid. I hope we all agree there should be only one such grid in any single document. Publisher seems to create more than one and then misalign them, on each side of a spread. (MacOS 10.9.5 + Publisher 1.7.1)

    Having auto flowed text into my new document, I noticed misalignment at the base of the third page (RHS of first spread after a single page starting a chapter). I was then astonished to see a second baseline grid appear within the RHS text frame, misaligned with the document one. Screenshot attached.

    Have to say also that 1) it is far from clear to what entity the grid belongs (it appears as an optional attribute, with setup, to document and text frame), and 2) display is similarly confusing since it appears covering whole page when start from Top Margin is selected.

    I'm afraid this is damning. It renders the package unusable for the typesetting of any book. If it is down to an older version of operating system then fine, but please don't claim to support it. I cannot upgrade the system, losing InDesign, unless I know issues like this, and the other two I've posted (failure of Insert Section Name, odd behaviour of tab) are resolved in the later version.

    You guys at Infinity should know there's a lot of people looking over our shoulders out here, as early adopters. Speedy resolution at least of the fatal flaws will make a huge difference to take up.

    Affinity_Baseline_Grid_Problem.tiff

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.