thomaso

Though workbooks, tutorials or help texts don't replace reference manuals, – here some sorted link-lists to Serif's video tutorials for APh + APub: APhoto – posted by @v_kyr, 2020 dec: APublisher – posted by @acapstick, 2019 june + @EmilyGoater, 2021 march

Ironically we can convert a Picture Frame, containing a bitmap fill + an image layer, to curves, without losing its picture frame features (UI) and without creating/converting any existing content to a bitmap fill. Instead the result appears buggy: Though the bitmap fill (before converting) still is reported at various UI spots to exists, it doesn't show in the layout, so now "Convert to Curves" seems someway to prevent a bitmap fill … and thus vice versa to a converted image, which forces a bitmap fill. (not in the video: Via Fill Tool I can load a new bitmap to this converted Picture Frame – again without getting it displayed in the layout though the UI reports it in the context toolbar and the various color wells) picture frame - fill & image - ConvertToCurves.m4v

I don't see a reason why the way of "thinking" would prevent the app from displaying existing info. There doesn't seem to be any purpose in this behavior. It's not that I don't recognize how (~why) it happens but rather for what goal / use / advantage. (Besides the fact that I am not really missing this info, different to the OP, I am just curious to understand the concept of Serif / the developers) ps: You seem to mix the Affinity terms "image" vs. "picture frame". They are quite different – the image (frame) is more similar to a converted image layer (curve + fill) than to a picture frame, which can include both, a bitmap fill + an image (... besides additional content like further image(s) + vector object(s)).

Just a note to «how the application "thinks"»: The app currently is willing & able to handle, report + give access to various kinds of content of a selected layer: An image layer does get its pixel resolution AND its vector stoke properties reported. From that perspective the thinking of the app appears oddly limited once the border of such a layer gets converted to an editable shape, as if the thinking would lack in multi-tasking. So it's hardly comprehensible that "Convert to Curves" interrupts access to the existing image information.

This sounds even more disturbing. Walt, does it mean you can't replace just 1 of 2 instances? It is possible for me and I assume this behavior as being imperative. Imagine you start an .afpub with some identical images as placeholders to become individually replaced during the layout process. – Walt, isn't that possible for you?

I have done it months ago with a small app. Since then macOS reminds me with a message window every few weeks to update the program, even though I have deselected all auto-update options in the macOS system panel (while the app itself has no update option or setting). Bit annoying macOS behavior.

To me it is. – Mac only? Can you show your experience on Windows? In this clip you also see the problem of object selection within the manager: not the selected layout object is accordingly selected in the manager but its folder 'only'. resource manager - folders.m4v

The question was related to the curve's content, the image, converted to a bitmap fill. The curve can be edited separately from its content, so curve & fill are two different things, the bitmap is hardly the curve itself.

Hi dr.jamesmoore, Welcome to the Affinity Forums! Would you mind to change your user name? Your published email address might attract spam, to you or to the forum. (At least) if you purchased via Serif Store the older versions are there: https://store.serif.com/de/update/macos/publisher/1/ I don't know about the procedure for a Mac / Win App Store purchase, maybe someone else pops in with more info. In case you picked this thread accidentally: the mentioned v.1.8 isn't the current one. Your app, once installed, will guide you to the newest update via its "Check for Updates" option.

That's a good question. It would be good to see what the original resolution of a bitmap fill was. Especially since there doesn't seem to be an option to reset to its original dimensions, only to original proportions. Though I would not mind to see the info I doubt it would be really useful (~ necessary) in practical use. As mentioned above, considering that a bitmap fill gets mainly used as pattern it is therefore downscaled, hardly increased. The various options like repeat (~stretch), mirror etc. do imply that the initial image doesn't appear in its original size and also there are options for interpolation to reduce possible jagging. Also note that there is no option for distance when wrap or mirror is used, that means you would prepare such a resource especially for this use (e.g. add a white margin) and would set its size accordingly, well knowing it will be used in smaller size. So, in case you want to achieve a specific result (different to just experimenting) I guess you would need to do some calculation anyway before using a bitmap fill.

Does one know what "missing content" means? (appears at a .PDF and a .SVG) Also I want to add a suggestion to the topic's panel improvement list: The column "Status" appears to be redundant if the column "Placement" would be used instead. As far I understand an Embedded resource never can be missing + every Missing resource must be a Linked resource. So it could work to have in "Placement" 4 variables/entries: – Linked – Modified – Missing – Embedded EDIT: "– Modified" added to the variables

It looks like a different rendering method in the Photo persona, and not influenced by the Pixel Alignment setting. As if the image gets blended with itself when moving. screen view APub & APhpers.m4v

With OPT + SHIFT + UP/DOWN you can adjust the baseline of selected characters (– instead of the paragraph leading / line spacing).

Instead of asking only "Why don't they make the interface like I expect it?" one could also question "WTF let me expect it different than it is?"

In case you haven't noticed: meanwhile this topic has moved to the feedback forum, here any discussion fits. Though even here it's useful not to mix various subjects unless you don't mind. Subjects in separate topics are more obvious to the community because of their separate titles in the thread list view. I am sorry, I haven't been precise in this previous post. Actually by "convert to curves" an image gets converted to curves (with editable vector shape) but not rasterized. This way its resolution is maintained and can be fully used in a possible pattern or still increased without loss according to its original resolution. If you do an action which requires rasterization (e.g. applying a filter in APub's photo persona) then the app does warn you with a temporary assistant message in the upper right corner. (by the way: there is a feature request for a longer duration of this popup) The Layers panel indicates various types with its label texts in round brackets. Curve vs. Pixel: While converting to curve doesn't change/influence the image resolution, rasterizing "burns" (fixes) its resolution according to its current size in that moment, so for rasterizing the current object dimensions + document resolution are relevant. When up-scaled after applying the command they may appear in different resolution (depending on their dimension at the moment of the command).

The fact that APub is mainly (not only) an app which increases the workflow efficiency of the available design, editing and layout features of AD and APh makes me assume that a feature of "Scriptability" could cause a series of other missed features become available. From this perspective a Script interface is a true essential feature, also for those who don't do coding. It wouldn't mean that Serif / Affinity couldn't implement features which became real at first as such scripts – rather the use of such scripted features would cause user feedback for preventing bugs and improving a final, native implementation.

As pointed out above in various ways this behavior has useful reasons. So your "definitely" and "should" sound neither necessary nor useful, especially if you consider to make use of the additional option for assigning keyboard shortcuts for your preferred kinds of conversion. Can't be easier & faster then to use only the desired, expected function. Also mentioned above there are two forums to discuss such ideas. I definitely think you should use them instead of this bugs forum and additionally increase the chance that other users might find your thoughts. You might notice that the according forums are read / used more frequently – in particular to discuss impressions / feelings like yours in this case.

This is the forum for bugs, there is a separate forum for feedback and one for questions. – Not every unexpected behavior is a bug in terms of programming. Though there is a flowing transition between buggy and unexpected behavior the major difference is the intention of the code, respectively of its initial concept. Offenbar gibt es für bugs bzw. die Programmierfehlersuche sogar eine Norm, was meine deutsche Seele erstaunt und quasi auch beruhigt. Schwerer nachvollziehbar ist im Deutschen die übliche Formulierung "by design", die einen bug vom nur unerwarteten Verhalten unterscheidet. "By Design" bezeichnet dabei alles was zwar unerwartet sein kann/darf aber nicht fehlerhaft sondern als solches geplant/konzeptioniert/beabsichtigt ist. Use case: you want to fill an object with a pattern. This feature enables you to create such pattern easily with a kind of automatism – instead of duplicating or editing such a fill in details manually. Color space: usually all objects within an .afpub use the same color space set for the document. This feature makes it easier not to need to care for color spaces of placed items. Resolution: a bitmap (image) fill is useful only in relatively small sizes of the image, e.g. 20% and less. In such cases a usual image resolution of min. 72 dpi will be sufficient because downsizing the image within the fill does increase its resolution accordingly. Compare: Vector & Texture Brushes in AD / APh, which also use an initially high resolution image as rasterized bitmap and don't offer or require control of the texture's DPI. There are very rare tasks within Affinity with no way back (those display an extra warning dialog). Almost all actions are 'undoable', either directly after use or at a later moment via the history panel, which offers "branches" for additional undo options. The Help says: Ich bin sicher, du wirst dieses unerwartete Verhalten nicht mehr oft erleben, denn du lernst automatisch, es vermeiden zu wollen und stattdessen die alternativen, extra dafür geschaffenen Möglichkeiten für verlinkte Bilder innerhalb individueller Kurven-Formen zu verwenden. Neben den Menus liefert vor allem die Ebene-Palette dazu die nötigen Features und unterstützt dich dort zusätzlich mit visuellen Indikatoren. z.B.:

Actually all parameters in the Pinning Panel concern the pinned subject in relation to its parent object, while each setting refers to the object. You can read the parameters in the Pinning Panel from top to bottom like a sentence, e.g. "Float subject A aligned at X of object B with offset Y" … FLOAT the subject A (= the selected object, which enables the panel at all) HORIZONTAL ALIGNed at X (various options) OF the object B (various options) with the additional conditions of OFFSET Y (= its offset relative to the object) and do/don't KEEP the subject WITHIN the BOUNDS* of the object (e.g. to avoid intersection of subject and object even if offset is set to intersect) * Bounds > see bounding box My guess: because effort and profit differ too much (…and might not prevent entirely from semantic confusion, too) Note: Affinity, called* "professional", expects some (not documented / defined) experience and understanding of terms within a design process. * "Affinity Publisher is the next generation of professional publishing software."

Please try again, avoid guessing. It works like this: The image gets rasterized and becomes a fill. The options of such a bitmap fill can be set with the Fill Tool. A fill image can't be linked but you can load another image to replace a current fill image.

With your .afpub I get a lot beach ball delays even with simple tasks like activating the offset value text field in the pinning panel. So I also assume your .afpub got corrupted somehow, wonder what might cause it. Possibly any document size related after pinning/unpinning, e.g. changed page properties like facing or margin or delete or move pages? – In a short test don't experience issues with such a pinned object: pinned_text_frame_float_at_margin.m4v

• I don't get issues with converting a picture frame into curves + editing its shape, the image remains in the frame + listed in the resource manager. • There you also find color space + profile listed in the details section of each single entry. ("find incorrect ones": note, your document's color space can handle others, too, + gives you options how to handle them within .afpub and/or on export)

Same in 10.14.6 Mojave / see in the video at 1:05 – 1:10 min.

Oh, of cause, you are right. The "math" seems to be that only with "None" the image gets cropped with the inner handle & and scaled with the outer handle – while with all 3 other options it always gets scaled with any handle and therefore doesn't need an outer. Stupid me, I even obviously had forgotten my previous related report for beta v1024 about the Picture Frame Property as Default et al. So the confusion appears to be caused (or increased) by contradictory AND inconsistent behavior of 1 certain property setting: In the video below the 1st picture frame gets created by dragging/tool and has its Default "None" applied as expected and saved in the Defaults – while the 2nd, upper picture frame gets created via conversion. The converted frame initially appears as cropping only & without outer handle – though its property is indicated to be set to "Scale to Fit max". After changing the setting to "None" + back to "Scale to Fit max" the frame behaves different and does scale now, not crop – so it has two different behaviors with the same setting. However, the expected setting directly after conversion would be "None", as saved in the Defaults and as applied to a frame created with Picture Frame Tool. picture frame - convert & properties.m4v

It's reported a few times … https://forum.affinity.serif.com/index.php?/tags/afb-4577/ Not sure if it is intended to be resolved according to this release note: (I still get the issue in a German OS + English APub) @Kaffeepause, bin neugierig interessiert: Wie erzeugst/aktivierst du die Darstellung der Tastatur-Keys in deinem Video?