Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by sfriedberg

  1. The Affinity Suite does not currently support scripting, so there is no way to write automation scripts. You might be able to cut a note text or image object from Scrivener and paste (outside a text trame) in Publisher, then quickly set scaling (Transform) and pin the result. But you will have to experiment.
  2. +5 This would be tremendously useful for text-based assets, and the Affinity Suite ever gets true object styles (not the current "preset" behavior) it would be equally useful for graphic object assets.
  3. Languages are all unchanged from a default install on an English language Windows system. General preference language is English (United States). Character > Language: Spelling is English (United States). Character > Language: Typography language is Auto. Character > Language: Hyphenation language is Auto. If I had to make a guess, I would guess this affects about 1% of my expressions involving a subscript or superscript i, and it does not always affect an expression which previously had the problem. Furthermore, it I can get the problem to stop (without ultimately inserting or changing any characters from the originally affected sequence), then when I save the file and reopen it, the problem stays stopped. So it's not going to be easy to reproduce. When I have more time, I will attempt to strip out 99% of the document text and all the illustrations and see if I can get the problem to recur with a smaller file.
  4. OK, I will add swapping the thin space out for other spaces to my list of experiments to try the next time I run into the problem. Inserting a zero-width space did clear up the last occurence, so I will try some others.
  5. Well, this happened again this afternoon, and this time overwriting a 'k' did not clean up the problem. The affected character was U+0069 ('i'). It was followed by U+2009 (thin space) and U+2219 (bullet operator). I am pretty sure I have seen it with other following characters such as plus and minus, but cannot be absolutely certain. In this specific situation, the thin space had default ([No Style]) character styling, while the affected character had a character style assigned with a font size reduction and a baseline adjustment. Toggling Unicode on the affected character did not clean up the problem, but toggling Unicode on the thin space replaced the dotless i glyph with the expected dotted i. Toggling Unicode off the thin space restored the unwanted dotless i glyph. I could repeat this indefinitely. I inserted a zero-width space immediately after the affected character, in its character styling span, and that cleaned up the display, restoring the expected dotted i. I have very many occurrences of these exact sequences of characters and character stylings, a great many of them cut-and-paste from earlier occurrences. (This motivated my earlier request for adding styled text snippets as an asset type, but that's neither here nor there.) It is significant that most of the occurrences don't show the problem, and that I see the problem only rarely when making edits by overwriting characters. To generate proper math expressions (or at least as close as AffPub can come right now), I am changing character styles on practically every character in the affected sequences. In addition to characters with explicit character styles assigned, I have many characters with a character style and a local (non-styled) override. It would not surprise me at all if the transitions between character styles are contributing to triggering the problem. Some experiments that did not occur to me, which I will attempt the next time I encounter the problem, include 1) typing additional characters before the affected character in a span of the same character styling and local overrides, and 2) deleting the affected character entirely followed by inserting it in the styling span of the preceding character then restyling the newly inserted character. If an Affinity staff member (eventually) sees this, is there any value to saving a copy of my document at a moment when I have the problem? My impression is that this is a transient display issue that would not be captured in a saved file, but perhaps that's too pessimistic.
  6. When you've pinned an object, you then have to move the pin, rather than the object itself. Or unpin the object.
  7. Here's an example. The trick is to pin float, with horizontal alignment set to outside right (or outside left) of the column. Sidebar Pinning Example.afpub
  8. I will try to capture the information about the following character(s) the next time this happens, and update this thread. From the specifics of this particular document, it is most likely to be a thin space, a plus or a minus (not a hyphen). I just now discovered Text > Toggle Unicode, which will give me confidence that what I report is accurate. Because it usually does not happen, it's probably not as simple as "if following character is x, then mess up". But maybe we can figure it out.
  9. On three or four occasions, I have encountered an odd problem, which unfortunately I cannot reproduce at will. I have some math expressions involving subscripts. Rarely, when I select a subscript character and type an "i" on top of it (to change the old subscript to an "i"), I get a dotless i displayed. I cannot say if this is the actual Unicode dotless i glyph (U+0131) or a display glitch. Once this happens, if I type an "i" or a "j" on top of the affected character, I continue to see the appearance of dotless i or dotless j (U+0237). If I type another character ("k" is the one I normally try), then I get the expected glyph and the weird behavior ends. Specifically, if I then type an "i" or a "j" on top of the previously affected character, I get the regular i or j glyphs, not the dotless ones. It should be really obvious, but I will state it explicitly just to be painfully clear. I am not changing stylistic sets or other typography settings when writing a character on top of an existing subscript character. The "subscript" characters are implemented through a character style involving font size reduction and baseline offset, not by use of the subscript OpenType feature. Preceding and following characters are generally in a different character style. Font is typically Cambria. Almost all the time, typing an "i" on top of an existing subscript does the right thing. So this problem is rare, but common enough to recognize as "oh, that's happening again". I saw this problem with the Publisher 1.8 series, and saw it again with 1.9.1 recently.
  10. I agree this topic (high-end justification) should probably have its own thread. But it's so nice to have something in this thread that's not "me too" about wanting/needing/craving footnote functionality. 🙂
  11. quoted from https://www.cufonfonts.com/font/luna-sans . And from https://www.fontmood.com/font/cristiano-sobral/luna_1561613932/luna-regular/mood-luna/palette-17616 , I wasn't familiar with either of these (Luna or Alegreya) but I am fond of incised fonts, so this was a useful thread for me. 😁
  12. I request a display mode (similar to Text >Highlight Fields) which puts a highlight over all spans of characters styled with anything other than the assigned paragraph style. In particular, I'd like to be able to quickly scan for spans of "No break" or manually adjusted tracking without having to move my cursor through the entire body of text. If the assigned paragraph style is Body, and the context toolbar reports Body+, the character at the cursor should be highlighted. But it should also be highlighted if any of the Character panel attributes have non-default values (e.g., Auto, 0, 100%, Off), like "No break" or adjusted tracking. These generally do not add the "+" to the style reported on the context toolbar, but should be highlighted.
  13. This is another situation where proper object graphic styles (not what Affinity currently calls graphic styles) would help tremendously. You'd assign one style to all the curves which need to have the same stroke width, regardless of how the curves are grouped, nested, or even what pages they are on. Then you'd make one change to the style and all the curves assigned to that style would instantly update. This is, for strokes and fills, exactly the sort of behavior you get from text styles for text, and is the behavior most vector graphic programs provide under the name "graphic style". Affinity really needs to supplement their current "preset" behavior with actual assignable, live graphic styles. My 1st paragraph simplifies a little bit, because you have both strokes and fills to consider. So you'd want build a graphic style hierarchy which lets you distinguish all the various different regions on your characters, using inheritance to make it as simple as possible to update stroke widths.
  14. Not a chance! Sorry. Do it the way you already know works: export the pages as images, place the images.
  15. Not yet, no. Remains an object of persistent (and loud) desire.
  16. You may be running afoul of baseline grid alignment, which can override cell vertical alignment. Confusingly, the document pages, text frames, and tables can all have their own baseline grids. Try turning on "Show baseline grid" and see if your table contents are snapping to the grid(s). If so, you can go into the Studio Table panel and set "Ignore baseline grid".
  17. +10 And if MathML (or embedded TeX/LaTeX) is not in Serif's plans, then PLEASE implement a plugin API with sufficient power over character transforms so we can adapt MathJax or a similar existing solution. These tools already exist, and we'd get access to the math expression functionality a lot sooner if Serif made it possible for 3rd parties to do the heavy lifting.
  18. I don't expect the standard dictionary to recognize limited technical vocabulary like "chiral", "achiral" or "dihedral", but the Affinity Publisher preflight on Windows doesn't recognize "involutions", although it does accept "involution". Worse, it judges "rotationally" and "lexicographically" as spelling mistakes, but accepts "rotationaly" and "lexicographicaly", which are simply incorrect. What dictionary is being used, where is it installed, and what format is it in? On Windows, the LibreOffice Writer spell checker is giving me slightly poorer results than the Affinity Suite. The antique Corel Ventural Publisher 10 spell checker gives substantially better results than either, as it recognizes "dihedral", "rotationally" and "lexicographically", for example.
  19. Just to summarize for those who didn't go read the other thread. 30-bit color support has nothing at all to do with HDR. 30-bit color is most often used by professional photographers and video editors for precision color grading. You need special hardware (both monitor and graphic card) for 30-bit color output as well as support from the software app. The Affinity software suite does not currently have 30-bit color support.
  20. Words. "Does not have any support" is not entirely correct. It has support for sorting words, and possibly for spell checking and hyphenation (dictionary-based functions) which is why Arabic shows up in those lists. It does not have support for correct rendering of glyphs. So your correctly sorted list won't look or print at all correctly.
  21. Most of Alfred's examples look like they are best done in Designer and not attempted in Publisher. For some of them, you'd really want a warp or mesh envelope tool, which Affinity Designer does not yet have.
  22. Probably because the logic for sorting according to Unicode rules for various languages can be implemented more easily and quite independently of the script engine logic needed to actually typeset glyphs in the same languages.
  23. There is a well-established bug with the Glyph browser and "math" fonts. When trying to display a math font, the glyphs are unreadably small, even with the largest setting available through the hamburger menu. However, I don't believe Gabriola is a "math" font. If it is triggering this bug, that's worth noting for Serif so they can track down exactly which OpenType feature(s) is responsible.
  • 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.