thomaso

I just checked whether this resolution/page-size issue is related to the document type. Now gets even more confusing: So, for instance, the page size does not change when you work in a document of Type "Web" and change the document resolution. But that page size change occures again in Type "Devices". That makes no sense at all to me. (and, why does in New Document Setup "Web" work with Pixels, while "Dimensions" with Points by default? And, if the various entries in the pulldown menu "Actual Size Zoom" are supposed to affect the 100% zoom view then it does not show any difference to me when switching between them.) That all gives the impression in the meantime, that the complete resolution theme is either not finished programmed yet or is incorrect in more than just some places.

Oh! – Do you find a link? I would like to read what was answered then. – (but you don't mean your quoted sentence of my post mentions the faulty, do you?)

Ich bin mir nicht sicher ob ich dein Problem verstehe. Schau mal in deine Ebenen-Palette, Seite für Seite. Könntest im Beitrag die Screenshots reduzieren, oder jeweils was davor texten? (ich sehe in 3+4 und in 5+6 keinen relevanten Unterschied) Weil wir hier in einem britischen Forum sind, schreibe ich mal englisch weiter ... I don't find any sentence in your description where you say what works other than expected. The only hint about wrong or right is quoted above: "... this works so far". <--- Ok, but what does not work for you? Irrespective of your text, I realize that although you have created a document with spreads of "facing pages", but that the first page is a left page in your document. That makes no sense in my view - and I wonder how you did it? Furthermore on the marked pages I see both of the symbols you used for left/right on master A/B. This can be achieved in several ways, for instance if a.) one master is a slave for the other, and b.) on some pages a master layer got deleted or set to invisible . So, to me it's hard to understand by your description and screenshots what you did and what you want. Things might get clearer for you if you take a look on the layers panel.

It looks to me like a mistake by APub's misread metadata, depending on the way a JPG got placed: While dragging the A.jpg from macOS finder into the document places the image in the expected size and resolution (100 x 100 mm, 300 dpi) – allthough the Recource Manager tells its original-resolution as 72 dpi. – The same resolution 72 dpi is shown by Manager when the jpg got placed by Place Tool, but then in different size (416,6 mm, 72 dpi). That said, APub knows the right metadata, but it sometimes processes them incorrectly. Correct size, if JPG got placed by dragging: ... Faulty size, if placed by Place Tool: ...

If I change for an existing document in "Document Setup..." the document resolution, then the visual size of existing and newly placed images remain the same relative to the page, but the document ruler simply scales and tells different sizes, the page size included. A check in "Page Setup..." confirms this change: there the page size varies with a changed document resolution. So a change of the document resolution results in a change of the output paper size. That is, at least for page type "Print", an unwanted and risky result. –– Or do I misunderstand this function? Before document resolution change: 300 dpi, size A4: > After document resolution change: 72 dpi, size 1237 mm: > By the way: Interestingly and fortunately, the export resolution does not affect the page size, but only the resolution of the content. Perfect.

Hm? A swatch gets a name from the application. If the automatic name is no longer correct, then it is wrong. A wrong auto-name is a bug. It would not be an error if the name was a user-defined name entered by the user. Compare: You create a new textframe. Its properties appear automatic in the transform palette. If you drag the frame to change size or position then its properties in the transform palette will auto-change, too. – Would you call it just "undesirable" if you would have to type its correct properties in the transform text fields – after you have changed values by dragging?

It's even easier: 1. auto-re-naming happens only if a name shows the color values, and 2. once a swatch got named with custom name by the user it will not become renamed even if the values get changed. The current solution automatically assigns a first name of the swatch and names with color values, but will result in incorrect names as soon as the user changes color values without manually changing the name.

@kai2, when I recently opened and exported your first document ( https://forum.affinity.serif.com/index.php?/topic/73780-pdf-export-alert-revisited/&amp;do=findComment&amp;comment=386319 ) I did neither get a warning message when opening the file nor when exporting it. So I was not aware about the ? in front of the font name in character pane. As I noticed with your second doc ("test-logo"), for my exports the font Frutiger was not activated – and in the PDF apparently Lucida Grande was used instead: That made me now activate Frutiger after opening your test-logo.afpub (which opened without complaint) – and now I get the same error message when exporting as PDF/X. – So I agree to your supposition that the font here causes the export issue. I tried other weights than "56 Italic" (which you have used?) and they did export fine, e.g. "46 light italic" and "57 bold italic". It reminds me to a similar experience with the font Univers, where only particular weights could get exported as PDF/X and others resulted in an error message. I give up at this point. For now either the font file might cause the issue on export or it happens while PDF import or even the imported PDF could contain the failure-cause already.

I might misinterpret the intention of the cursor position marker in a text ruler but since it does often occures with an offset, from tiny up to even out of my window, I assume it meanwhile to be a bug. It does not happen always but often. – Here some examples + the according .afpub to check: The distance of the markers one to the other remains the same but with an offset: > The markers offset can become massive, both to the right or left of the frame/ruler: Influence of frame width: 170192 text ruler cursor marker.afpub [ p.s.: It was discussed here before: https://forum.affinity.serif.com/index.php?/topic/73921-text-ruler-text-cursor-marker/&amp;do=findComment&amp;comment=384885 ]

@StevieB, it is a normal, expected behavior: It happens when you set your paragraph to centered. Obviously this centered applies only to text behind the last tab, which makes kind of sense, because 'centered' is relative to the frame's width (in difference to a tab). To achieve what you possible want you simply don't set the paragraph alignment to centered but the tabs only. In this sample the first paragraph (tabbed) is left aligned, the second is centered: Indeed: It could even be easier for a series of equal tabs, if it would be possible to set the default tab alignment. Then it would not be necessary to define every single tab but just the first one, which, yeah!, auto-copies its distance to the following you typed in your text frame. In the following sample 3 auto-tabs are generated in distance of the main entry (here: 20 mm), but unfortunately there is no choice for their alignment. Also the alignment of an additionally defined first tab (here: 10 mm) is ignored by the auto-tabs in its alignment, but, luckily, in its distance, too.

Swatches Pane > Document Palette: I am not able to get a global gradient color swatch. 1. When I use a click of the tiny right gray palette icon next to the pulldown menu then nothing happens. 2. When I ctrl-click an existing gradient swatch there is no entry "Make Global" - as it appears for plain colors. Since I can not imagine this to be a deliberate feature I assume it as bug.

Pic 1 + 2: the unwanted/unexpected/failing windows ... and Pic 2 + 4: their wanted/desired/working equivalent : Unwanted: color selector window ignores various colors of a gradient and reduces them to 1 only: Expected: color selector window differentiates between more than 1 color of the gradient:

Swatches palette: 1. When I double-tap a gradient swatch then a color selector window pops up. 2. As soon I move any slider, the swatch changes from gradient to plain color and the gradient is gone. • I can not use the undo menu to get the gradient swatch back; the swatch edit does not appear in the undo history list, similar to other swatch panel actions. • This behavior of a gradient swatch color change is not dependent on whether an object was selected before the swatch edit, or only the swatch alone. So the bug appears to be ... ... the lack of the gradient options window here as a step before the single-color-selector window. * ... the missing entry in the undo-history This lack of the gradient options window occurs also when you hit the round gradient preview in the up left corner of swatches panel. * I'd expect those edits to work like the fill box gradient section in the menu bar: There you first choose a gradient color node before edit "the"/any gradient's color. p.s.: comparable but not equal: https://forum.affinity.serif.com/index.php?/topic/74239-colour-swatch-inconsistency-between-apub-and-ad/&amp;do=findComment&amp;comment=387410

Yes, @walt.farrell, thank you! Excuse me, I did not notice this palette because it appeared modest on the area of the similar-looking pages palette on the secondary monitor. I agree, on the one hand it can be nice not to lose this window as long as it contains files. On the other hand, I would like to keep all unplaced images only if APublisher treats images differently: Currently, the Placement tool loads the full file content before it is placed - instead of just preview and file path. This means, depending on the number and size of the files to be placed, it is quite demanding CPU + RAM. Test: Place a bunch of large images and compare your system activity window. In AFpub first it takes a while before the preview window appears, then, the CPU and RAM even stay occupied for some minutes when I interrupt (=quit) the place process. Related to the Place Tool and previews I would wish another feature: an adjustable grid while/before placing several files. Momentary I need to position and drag-scale for every single file I want to place. So it's hard to make all same size. With such a grid I would for instance just place the upper left corner and drag to the lower right to make them all auto-fill this area.

@DanEv, now I can repeat your bug: Obviously it is dependent of the selected palette. To me it happens only with System Palettes and those below in the pulldown list (Pantone). Furthermore: it is confusing that a marked swatch position remains marked after switching the palette: because of its position in the swatches, not because of beeing selected. Very useless, and risky with similar colors, too.

@kevinmcsherry, your document can be exported as PDF/X-... : On both your master pages is a text frame placed into a text frame which apparently is not meant to be seen/printed. Set them in the layers panel to invisible (on both master pages) and the file exports as PDF/X. Like a charm. _________________ p.s.: to avoid this in future it might help not use a text frame as color background shape. Rather use the rectangle tool or one of its shape family instead. p.p.s: the artistic text is not necessary for text, unless you want to deform text. You might remove its tool icon from the tool palette and replace it with the 'double' text tool to avoid misuse. p.p.p.s: your signature. huuu. It almost fills my screen. what for? Would you mind to calm it down, please?

@kai2, to me your document exports with PDF/X-4, -3 and -1a preset at 300 dpi without complaints. See attached. test-X4.pdf test-X3.pdf test-X1.pdf You might check these pdfs to look for any disturbance. (I can't judge what I see because of not knowing the original material). p.s.: What do you mean with "logo"? There are many elements forming such a thing, I can not recognize one or more of them as "logo" but just many text elements (most of them as curves) and 1 tiny foto "50". – Attach a file with "logo" only?

That might be but it does not solve the issue because I did my recent/last tests without having an object selected, but a gradient swatch only. @dominik, danke, und gute Nacht! War ein sehr konstruktiv-konzentrierter chat mit dir hier. Ich schreibe morgen einen Käfer-Bericht (falls du nicht schneller bist;)

It's obviously hard to describe. I might have lost you (or you me). For me there is no way to return with undo (comand-z). – Didn't you experience the same here? : https://forum.affinity.serif.com/index.php?/topic/74002-object-style-definition/&amp;tab=comments#comment-386161 However, we discussed this intensive from many perspectives to definitely know now: there is something not, hm, charming – but possibly cute like a bug

To me step 2. does not bring back my formerly gradient swatch. It shows a plain color only (with noise if applied). But now I see an even shorter way back to the - unwantedly lost - gradient (which works, ironically, because of another UI inconsistency;): 3. Click on the gray palette icon. Done. The swatch returns to the formerly gradient, because the circled preview in the up left corner of that window was not updated (= not loosing the gradient) when touching the slider before.

What else could it be? Just listen: "You click on a gradient swatch which opens a window where you can do nothing but unknowingly and erroneously delete what you came with, irrevocably.." Would you name such behavior a feature? Edit: I had a previous screenshot in mind, sorry. The one you quoted is indeed borderline.

1. In "Swatches" panel > "Gradients" tap twice on a swatch. 2. Now the color option window pops up. No gradient options there. 3. As soon as you touch any color slider / or color in the color field / or the noise slider : The gradient is not-undoable lost. So the bug is this two: 1. Wrong color selector window here. It should be the one for gradients options (= the one from "Fill"-box in menu bar). (The color selector should appear in a second, later step: if you click the "Color"-box in the gradient options window.) 2. A tap or click on color or noise in this window is not-undoable. Wonderfully! Thank you! I haven't seen the "Bitmap" before because I tried the "Fill" box only. There the "Type"-menu is reduced to: But, oh, what happens if I have filled with a bitmap and then open the Fill box: The "Type" in menu bar says Bitmap + the Fill-box-icon shows the bitmap – but in the "Type"-menu of the fillbox's gradient section there is a gradient and no bitmap. Though I had bitmap applied but no gradient. Is at least quite confusing with sort-of paradox informations. Imho is's related to the bug above: the UI seems just not finished, like interrupted for a coffee and then forgotten ...

In In a proper print file the color Black for texts is created in 1 color only, the k of cmyk. So it doesn't matter if the PDF contains rasterized elements of black text (= tints). I have no experience with additional costs for less than 100% k. My above costs thought refers to 'classic' processes such as offset printing or photocopying machines. There I only pay extra costs for c, m, y – over k. In this way I mean black as just one color, including all tints.

+1 (I yearn for it, too)

(p.s.: the topic was about document preferences, not about converting.) I agree to your hints concerning nowadays print color spaces. But I do see one massive reason to respect CMYK: The color Black. – It has several disadvantages if black text is defined as RGB instead 0, 0, 0, 100. Especially in nowadays automatic printing workflows it can both increase costs and reduce quality, too. So, for now, it could be risky to ignore CMYK. AF Publisher might enable a kind of document preference option for Black Text. Might possibly a snippet of code be able to recognize "text" and auto-set its colors to 100 K?