thomaso

Hi @MerrySherry, Welcome to the Affinity Forums! What value do you want to adjust and how do you check the result? For instance in the Transform Panel you can work with decimals of percentage, regardless what result is displayed in the field. In the app prefrences you may set to get up to 6 decimals displayed, and you may alter the displayed unit to make a tiny change more obvious.

You can use an additional object + layer nesting to enable the wanted workflow and result. This way strokes can get visually applied to pixel content, too. Also, converting a layer of type "pixel" to an "image" layer might help.

You can achieve both – no additional pixels & no rounded, blurred corners – by placing the Outline Effect inside.

Thank you! (for your monitoring, this post contains another example: the link should show at least two search results, currently it shows only the newer V2 post) Are the search results relative – or did the new structure alter the URL for old threads? In case of the latter any link within the former V1 forum posts would not work any more, right? While I agree to the plan to have all Questions in 1 forum (with old V1 threads auto-moved to the end just by their dates), currently I do see a link to "Pre V2" as a sub-forum on top of the Questions forum (click pic to enlarge): … which obviously still gets used (fine so far) and obviously not only for V1 questions (possibly confusing). So, I don't understand you (and @loukash) mentioning "not split" respectively "granulation isn't" because I do see the split. This split appears problematic especially if users do a search for possibly existing thread, reply to one of this subforum (archive) while their post will not occur in the list of the main Questions forum but "hidden" in this Pre-V2 archive (which displays only 1 newest reply, here Walt's, 19 min ago).

Correction: I just found the newly created set of V1 Beta Archive forums … https://forum.affinity.serif.com/index.php?/forum/135-archive-reports-from-affinity-version-1-betas/ … so they seem "just" to be currently not accessible for the forums search.

Currently it rather appears the V1 Beta threads not only are invisible but now are excluded from the search, too: The link in my post above now shows only 1 result (this current thread) while the initial result (as screenshot above) does not appear any more. (same result in a different browser / not logged-in). – Regardless of being beta or not those threads my help to communicate about bugs that still occur (in V1 or V2) by possibly reducing the need to repeat tests, screenshots and words. I agree these threads should be set to read-only. I even would appreciate the current V1 bug forum to be read-only, too, just to avoid the impression any possible V1 update might get these old bugs fixed. Since we are there: Currently this Support & Questions forum contains V1 and V2 questions – while additionally a separate Q&A Archive exists for V1 only, which doubles the number of V1 forums and thus may confuse, in worst case for instance if a former V1 thread of the Archive gets used for a reply concerning V2. – I wonder why V1 does not have an entirely separate forum, not as subforum of V2?

Serif has not 😉 … if I understand this correctly (and did not miss a newer info): Concerning Type 1 fonts there was this comment in 2020 and that in 2021, not really indicating an end of Type 1 in Affinity, let alone a date:

I've never experienced crashes caused in particular by Metal/hardware acceleration, so I thought it was mainly affecting the newer M1 Macs / Apple chips... whereas it seems odd that these are still getting the problems, since V2 has been recoded to avoid these problems on these configurations.

Affinity has known problems with Postscript Type 1 fonts. For my Univers I see an empty Affinity Glyph Browser, too, as for other postscript fonts, e.g. Meta, Rotis, The Sans etc. https://forum.affinity.serif.com/index.php?/search/&q=postscript glyph browser&quick=1

This bug affects Windows only, right? Whereas the OP (and you) appear to be macOS users. In my impression it is more buggy than V1. In the first month I was surprised about the fast growing number of bug reports for V2. I assume the number of bugs in V2 is larger than in V1 because of the fact that most long lasting bugs from V1 were not fixed before V2 got newly coded – in the sake of more stability / compatibility with newer operating systems / hardware (and leaving older behind) – which means theses V1 bugs got rewritten for V2. Some weeks after V2 release I added occasionally certain reported bugs to a personal list of interest to make up my mind about the V2 usability for my preferred workflows. Unfortunately the list of V1 bugs carried over to V2 is longer than those bugs which appear for V2 only. (while some of the V2 bugs even affect old features which were bug-free in V1). Since my operating system is not supported by V2 I judge only from my forum impressions. For some weeks I considered to create a separate boot volume especially for V2 usage to be able to try the demo at least but the continuously growing number of V2 bugs stopped this idea before it got realised.

Okay, you used a 2nd decoration where I used a character background colour. It appears I was mislead by your scaling-handle hint, which becomes irrelevant here if you activate "Scale with object" in the Stroke panel for the decoration.

@Seneca, sorry I can't open V2 but I am curious about your solution, especially since you mentioned the need to use specific handles for scaling. Can you show a screenshot or tell the basic properties you used?

Especially for UI design the "Constraints" feature might help to maintain padding and other dimensions. Unfortunately the Affinity UI for the Constraints Panel has no tool tip texts and may confuse, but there are a few tutorials around, for instance this quite detailed one:

@EatMoreBacon, since you mention ID, is your .afpub based on an .idml? As Walt mentioned, there is a known bug with imported .idml. (I can't install V2 to check but would have expected that in the "next generation of Affinity, (…) setting a new standard in the world of creative software" at least general bugs would have been fixed?)

An easy way would use no tabs at all but centred aligned text + paragraph decoration + character background colour: centred txt & char bg col & par deco.m4v

Yes, they work the same for these workflows. (my example is from APub v1)

As long as Affinity does not properly understand 1-bit images but converts them to RGB, another workaround to achieve white as transparent would require the image to be saved with transparency. In CMYK documents it needs the option "K Only" activated when a fill colour is applied.

Yes. One reason that the music nomenclature / notation did not change might be that is more related to a mathematical language than to typesetting or graphic design which yearn for flexibility. Nevertheless, there appear to be desires to modify the way of music notation (as you assumed: because of the number 12 and altering # and b), here a hint from "dozenal.org":

@jackamus, with other words, while the old technology handled with physical objects which get literally 'put' inside, in DTP no such object exists at all and nothing get 'put' but rather a value only gets changed. Thus a comparison between physical versus virtual may appear less related then e.g. legs with wheels, both physical. (Btw., should we indeed call the legs of a table 'legs' … or call a table in DTP a 'table' or a 'shelf' … etc. ?)

True. But in my eyes this problem starts as soon a comparison gets used. It compares different things, expecting they would not differ. I would say there is also development in music notation. One obvious change occurred when percussion appeared and got its notation, too. Apart from this modernisation of notation, I would rather compare music notation with the alphabet and its letters - than with the technical processes of typesetting in DTP, which compares to keyboard and various interfaces to the digital process. But back to this thread, / a former question about a technical aspect of development in DTP: I prefer using numbers to denote height as opposed to Primer and Long Primer and Brevier and Pica and Small Pica and.... All I can recall from years back. … while @jackamus had a less specific answer: Maybe my question was unclear: I want to know a technical reason for a difference in digital font height whereas I would expect that it would be handled as in lead letters where a certain body (?) (german – engl.: ~körper / fleisch ~flesh) did not vary. In the sample below I am not referring to the height of the black characters (which may vary of cause for a certain font size) but I wonder about the differences in the height of the blueish background (which appears to correspond with the highlight area of a text selection) … while, of course, the handwriting font has to differ to correspond with the x-height of grotesk type. • So, for what purpose (advantage, technical reason) do Arial + Corporate exceed the set height of 15 pt from the centre while Bodoni + Futura are rather moved downwards? • And why do Arial / Corporate exceed their text height with their 'box' at all while Bodoni/Futura seem to fit in their 'box' exactly? • I would expect they all would take the same 15 pt area (indicated by yellow) as their limit and none would exceed the common height but stay in their "box". (again, handwriting excepted). It seems, none of the samples fully respects the set 15 pt. How come?

For me, there is nothing wrong. It just didn't happen, perhaps to avoid confusion due to the different workflows and possibilities that could lead (!) to questions like "Why are they named the same word if they are not the same thing?" … What would be wrong to call the 'wheels' of a car 'legs', as we were used for horses, since both have the same function and result: if moved correctly then a space gets increased …? We even could say a car or horse is clumpsing, leading or regleting …, with the idea to make something less complicated. Indeed, it makes little sense to compare these two technologies or their terms, except for historical reasons. Then we can go even further and wonder about the ethymology of the words, which may help to understand the history but not the differences between this two technologies.

This is impossible on Mac. As the greyed-out app interface (toolbar) in my screenshot shows, not only this dialogue must be confirmed by pressing "Okay" before the app accepts any other user action, it also may close dialog AND the document, leaving an empty main window but still showing the running / frozen "Save" process. So, there is nothing left which could get saved, especially because this state requires to force-quit the app. But also without a frozen "Save" process the "Failed to load" dialog window does not allow any user action different than confirming "Okay", while pressing "Okay" immediately closes the document, too, and thus not leaving a chance to restart the "Save" process.

... a real need to use master pages at all 😇 … or even require a certain layer hierarchy because they don't have overlapping objects. While a statistic of layout types (card, letter, brochure, etc) hardly exists any guess about all or an average of projects & users appears not useful respectively is simply misleading … whereas a statistic would be more reliable for the most frequent text colour printed in pure 100 K, for instance (… in case we would consider a usage statistic as an argument for a feature decision.) But back to this topic and the various concerns about the request: What would be an average or reasonable max. number of master pages applied to document pages – and what would be the number for those situations where applying masters on masters first + then applying only 1-2 masters to document pages would be a more efficient workflow? Also I wonder how relevant a verbose master page name would be in fact since every master has a visible layout, too. Which seems to be related to the question about a max/average number of used master pages (since "A", "B", "C" would be easier to remember than e.g. 25 master pages)(which reminds me to your "applied 100 masters" that I still can not imagine to ever happen).

I'd say it is rather a common use case: As soon the layout contains individual page-level objects which exceed the margin / enter the bleed. That may occur quite likely in magazines, brochures, catalogues and photo or illustrated books for instance … which cover a wide range of projects that have page numbers. Even if you use a full page picture frame on a master, you can't clip a placed image on a document page without the need to detach its master first. Additionally cumbersome: you need to scroll up in the Layers panel + select the parent master layer to choose "Edit detached" though you may currently have the placed image selected for editing. (p.s.: "rare" … what kind of project did you have in mind above when you mentioned "applied 100 masters"?) Well, this is halfway to Global Layers. It would allow top most + bottom layer position across an entire document, then still anywhere in between could be missing.

It became necessary by your ID comparison respectively your statements for APub as "way more powerful" and "killer feature". In fact I would prefer not to read odd comparisons and weird attributions that require further comments to prevent their marketing speech from misleading. (p.s.: the handling of APub's master pages has several dedicated threads, too, right? This thread is about interface design, "No need to go into" master's usage:)