thomaso

I miss it, too. Though it is not a technical problem to tell/show the scale % and to enable to set a % scale (without the *x% workaround), I assume the team momentarily is still involved in other, also related issues. You might have noticed that in Resource Manager a placed image dpi value changes with the documents resolution – which is a bad bug to me. Also it is not solved yet that an image size on canvas is related to its file format: for instance a PSD gets placed in real/expected size whereas the same file as JPG gets placed in a size related to its dpi. – Just give them time. For now APub might not be a good one for your reasonable needs.

It was humble hidden in the file name: "...downsampl-bicubic.pdf" And, possibly, could you change the web-preset to bicubic? Finally: It is not very clear nor helpful, that a change of the preset in the export options also results in a change of the "More" options. I'd expect - like lars did, too - that they are either independent or, at least, remain once I altered them. Also, it would make things easier (less confusing) to b able to make all export settings in 1 window only, means to see the "More"-settings in the same window as the export options.

The problem/bug in Martins case was that APub does not export 8 bit from a 16 bit document. One needs to set the document to 8 bit to achieve an failureless 8 bit export.

Yes, "web" and its default 72 dpi - but with a change in "More" from its default "bilinear" to "bicubic".

@larsh , your unwanted look results from a downsample setting either nearest "neighbour" or "bilinear". There is no sense to use those for final documents, instead choose bicubic at least. If you switch from a print preset to web than paramters in the "More" section become changed in the background. That's way you thought not to have changed setting. @MEB , obviously the export preset "web" is linked to a) 72 dpi and b) bilinear downsampling by default. That bilinear preselection is the bug or should get auto-set to bicubic at least, in my opinion.

Sorry, I don't understand this line. – Klappt's bei dir jetzt? I don't get issues with your doc and jpg to export a 72 dpi pdf without your initial appearance: larshennings.de-teil_downsampl-bicubic.pdf That's a pity but a normal behavior, especially without master pages like in your document. Imagine a layout with objects not touching a margin – how should the application know where you want to get that object placed if you make a left page to a right one: stay or move?

What makes you think so? – Resampling (here: downsampling) was invented to increase quality by interpolation between merging pixels. But in the interruptions above we see a lack of pixels.

Low res would appear blurry/unsharp. Not the steps are weird but the interruptions in larsh's pic. Compare: Left: 1px lines in 72dpi ---- Right: same pic downsampled to 24 dpi and shown in size of the left image (300%)

Looks, like buggy to me, too. The horizontal wires should not show these interruptions, at none resolution. I think I've seen a similar occurrence when an application uses only the preview, which is stored alongside the overall data with an image file.

+ 1

Sharon, I don't have your dark-master-issue in light UI. – Might it help to reset your app's prefs?

Yes, this was a feature request in 2014 already – and MattP apparently did like it: Unfortunately not in developers main focus obviously. – But at least it is not at all a bug .

Ah, yes, lock children does work as expected. Thank you, fde101! – But then, what is the layers lock supposed to lock? The help text made me think it would prevent transforms. " To lock a layer (or layer object): (...) Select Lock/Unlock again or use the Layer menu's Unlock item, to allow the layer contents or object to be transformed again." That seems to work when I select locked layers only but not with their parent layer selected.

The layers lock appears not to have any effect to layers which are nested as sub-layers. They become transformed when their parent layer gets transformed. Here an example within a text layer, in which the objects inside become undesirably stretched: layer lock.mov

No export issues here with your .afpub. It exports like a charm both as PDF1.7 and PDF/X-1a. Test_Seite2_pdf1.7.pdf | Test_Seite2_pdfX1a.pdf Because I don't have your used font "Fira" it might be an issue with this font file? Are you able to export any document which uses this font?

"Current" has a predefined meaning by default, in sense of human language. A different use of it is a bug like any other wrong information which is given by the impression of an UI. Otherwise, every bug would just be an irritating word usage. The objects on the page are not what I am considering analogous to the items in the Finder. The pages themselves are.  That's even worse: in APub it is not possible to select more than 1 page/spread as "current", neither in main window, nor in pages pane or any other APub's place. So your macOS Finder comparison about the ability to have more than 1 item selected = current does not fit to this topic, too. Finally: if Apub really wants to export the "current" page this is a bug in code, otherwise it's a bug of UI-wording.

In your Finder example, you show that it is possible to select two different objects in different Finder windows, regardless of their folder. That is, you can select two or more different objects as current. However, this is not possible in Apub: if you have selected an object on a page, it will become un-selected once you select an object on another page. Since the current page print/export option may depend on the page of a previously selected object, a formerly selected page can be misused as "current page" in APub. The bug lies in the use of "current". The fact that it might be deliberately programmed to mean sometimes current, sometimes selected, sometimes displayed in main window, sometimes recently used etc. ... does not prevent the error in the use of "current".

This comparison dos not reflect the issue at all. The topic is not about a scientific idea or theory but about the meaning of the word "current". Like mentioned before it is more a semantic problem than a technical: APub handles "last used" as to be "current" – whereas "current" in common usage means present, not past. APub appears to mean "current" in different ways. For instance like mentioned in the APub help: << To add pages: Do one of the following on the Pages panel: To add a new page(s) before/after a chosen page, select a page in the Pages window. The thumbnail that's shown as 'selected' is independent of the page you're currently working on. >> Try this: 1. Select an object on a page. 2. In the pages pane select a different page with single tap. A blue rectangle marks it. 3. Hit the "add page" icon and see the selected page to be set as current by its preset page number in the add-page options. This "current" can not only be different to the page with the selected object but even be different from the currently displayed page in the main window. So there are 2-3 different uses of "current". And, yes, because they were designed that way. But this intention does not eliminate the mistake. (as every mistake was designed and programmed, otherwise it would not occur).

Hi @Chris_K, nope, I can not see a difference if a document is set to pixels or millimeters (except ruler units). In both settings, the "Placed DPI" becomes changed according to the set document resolution: Increasing the document resolution increases the placed dpi. So to speak, is a false information, both in pixels and in millimeters, as this information does not inform about the effective DPI value as it pretends or would be expected. Also, in both, pixels or millimeters, a change of the documents DPI does not alter the documents dimensions nor the dimensions of placed images. And even for new documents in pixels: e.g. an A4 document becomes by APub the dimensions of about 3500 x 2500 px, totally regardless of its selected DPI. But this, I guess, might be a different, additional bug.

It is not enough to explain your file size of 1.58 GB. The sum of the 15 used links is about the half of your .afpubs file size.

I assume the loupe is not made for use on color-wheels and - selectors. Instead in a wheel you may move the two white circles to select a color. Or simply click.

In case you ask how: 1. Select the object(s). 2. Select "Edit" > "Duplicate" to place a copy on same position. 3. With the duplicated object(s) still selected move them to the first new position. 4. Select "Edit" > "Duplicate" for any further copy: it will be placed with the recent offset. Weird in step 3: • the transform palette does not tell the new x-/y-values of duplicated objects but remains with those of the first selection's position. • if I make the move in step 3 not with mouse but by entering new values in transform panel than the duplicated offset is double than wanted. Possibly a bug? Can be done old school style, too: Include the crop marks in your selected objects of step 1. An auto-crop mark generation feature could become real later, for instance when APub becomes scriptable.

"Save As...": For now you still need to enter a new file name to make the effect effective.

... and your "Pack and go..." might be expected in the file menu, somewhere around "Save As..." and "Export...", to make it include the .afpub, too, instead not resources only. ... And I'd appreciate both DPI to appear more close to each other. ... and ... and ... less "fake" + less "great" would be nice But first of all I would want the value for "Placed DPI" to be realistic and the "Color space" would tell the resources's space, not the document's.

That's the question. And that's the bug. Do a search for "currentpage" – and wonder about its meaning, its usage, its common understanding ...