thomaso

Just a guess: You might check in system preferences > keyboard if your wanted keyboard language is still selected. Then, in keyboard overview, you might look up where the expected glyphs will appear. ( If I switch to Portugues keyboard then at the ´ key the + symbol appears, if I select Brasilian then it is the = symbol. )

Unfortunately, yes, still, in various panels. – But what a pity:

I have experienced such crashes, too. It happened in a document I work on since some weeks. I opened it, ignored the often complaint about missing linked images, and did nothing than typing a number in the lower left corner of main window. APub crashed 2x, after the third app restart it worked (– and does it since, so I guess it is not related to that particular document). I did not reboot the computer between the trials. Affinity Publisher Beta_2018-12-13-115522_mbp1.crash Affinity Publisher Beta_2018-12-13-115430_mbp1.crash

Since GREP means "Global Regular Expression Print", it appears logical to name this missing feature "grep search". It may be a coincidence, but not necessarily, that a newbie named Peter Kahrel has an eye on this topic. https://www.oreilly.com/library/view/automating-indesign-with/0596529376/

Would a different way possibly be? : 1. create two (single) master pages and define their different margins 2. create one third spread of two facing pages 3. apply the masters of step 1 accordingly to both pages of the spread.

Yes. Thank you!

Na endlich! Heureka! Mich interessiert trotzdem noch 1 Sache, please: Öffne APub v.192 !!, öffne das Test2.afpub (also das ich auch habe) , ändere den docfarbraum in 8 bit, und exportiere es mit diesen Einstellungen: bicubic > 300 dpi _ 300 dpi _ 85% _ PDF 1.7 _ document _ document und schicke dann das PDF. Okay? Danke!

I wonder, if APub does support jpg compression for 16 bit at all? If not it might be useful to remove the JPG option for exports from 16 bit afpubs. Or even to deactivate 16 bit as document color space? It might be less necessary in a layout publishing application than it could cause confusion – different to an image editor.

image frames hiccup2.mov

In the attached document a move of page 3 in front of page 2 lets the content disappear, as if deleted. Both in page panel, in layers panel, in main window and in resource manager. This occurence can be undone with history or cmd-z and is repeatable. 170192 image frames hiccup2.afpub The .afpub has 7 MB and was "Saved as..." from a document with same content which has 59 MB. The right of the two picture frames got created as copy by option-drag. In a previous .afpub version the images within the PFs appeared like linked: a move of one got synced to the other after mouse release, though they never have been symbols.

Yes. – There are no issues when dragging an image from a catalog into ... • macOS Finder, • InDesign, • Text Edit + other rtf text editors, • Microsoft Outlook Besides APub the only experienced application where metadata get placed instead picture is Microsoft Excel.

Any idea how to avoid if with dragging from a photo manager then APub does not place the picture but a text frame with its metadata instead?

When I increase in "Document Setup..." the document resolution, then in "Resource Manager..." the Placed DPI appears increased, too – instead of reduced. For example: increasing the document resolution from 300 to 400 dpi increases the placed dpi from a 300 dpi jpg to 400 dpi. Or vice versa: a documents DPI reduction from 300 to 72 dpi does also reduce the Placed images DPI from 300 to 72 dpi. That can't be correct.* * or would be a wonderful magic method to change lowres images to highres simply by setting the document dpi. ( this bug might be related to this different topic: https://forum.affinity.serif.com/index.php?/topic/66358-affinity’s-running-gag-not-honouring-resolution/ )

Unfortunatly - seen from the current amount of threads and posts related to this subject - I am afraid the "fewer support calls" might not sound as a very strong argument to the developers. But I agree: I'd prefer pages towards spreads as default. I wonder why the UI is created at all with a pulldown menu instead of radio buttons and check boxes, which would give more transparent overview. I just experienced (new in v.192 ??): Even with "All Spreads" selected only pages (not spreads) get exported when page numbers are typed into the pages text box which do not include complete spreads. For instance "6" exports only this page, not its spread. Or "3, 4-6, 9, 10" exports 1 spread (p 4-5) only and the others as single pages. – So, at least for such situations you simply can ignore the default "All Spreads". Btw.: I can't see how to print (not export) spreads instead of pages. – Is this not possible / not programmed in the UI of print options yet?

+1 ! I'd appreciate to have it stick to the recently used setting. Like it works already for page numbers. But those, unfortunately, are grayed out because "All Spreads" gets auto-selected in the background after every print/export. If the recent setting would remain then the unwanted default "Spreads" selection disturbs me only once, – and others too, who prefer a different default.

I must have misunderstood this. I meant the menu "File" > "Export...". In export options you may choose "Selection", that will limit the exported dimension, regardless of page dimension applied in Spread Setup. Serious? APub is not a backup restore application, especially not for actions the user does exterior of APub. But you might use a "get-file-back"-button on your computer to restore deleted files

@MartinHH, the buggy file size of output PDF might simply get solved with 1-click: In your document setup change the color from 16 bit to 8 bit. In your .afpub with 5 images the switch of document color space takes ca. 3 seconds (beachball) to be finished. In case it is related to the amount of images then you will have to wait quite a while in your entire document with 200 images. –> the resulting pdf has 1.7 MB towards 59 MB with 16 bit document color space. In the export options you will see the change in the estimated size, too: 16 bit: ... 8 bit: The calculating time for size estimation might be long with your entire document, but it shows the impact of the color space switch before you export. I wonder if 16 bit is an useful option at all if you have set, like in your document, the document type to "print": However, though you might be able now to export a PDF with reasonable size and quality, the huge pdf file size exported from a 16 bit document certainly is a bug: • A change of compression quality should have an impact on the resulting PDF file size. • A page in 40 x 30 cm, 300 dpi, should never result in a 59 MB pdf.

That's why I said "toggle in time with its "Sync"-button". – Button on > linked. Button off > not link. Button off > symbol will no follow. Button on > symbol will follow.

[ EDIT :: this content is partially outdated / read the next post first ] Martin, I got your dropboxed .afpub with its 2 pages, 5 images, embedded. First test: 2 pages, 40 x 30 cm, downsampling from 301 dpi, RGB, 300 dpi, jpg quality 75%: 59.7 MB Rediculous much. – There is definitely a bug in downsampling on export. It is an extraordinarily vicious process which creates a lot data garbage with exporting high-resolution images. Martin, I do understand if you decide to stop here. – Otherwise: ===================== Since in your original .afpub the images have 861-1261 dpi I did upscale their dimensions on the pages to 200% to reduce the max dpi in the placed images because APub offers its downsampling as limited from 600 dpi in the export options. Just to avoid such useless 600 dpi limitation. Downsample slider starts at 1dpi but is limited to 600 – indeed? : Resolution dpi (1): File sizes of .afpubs and its exports: Test2 = name _000_ = downsampling from _00. = jpg quality After resize images to 200% to avoid any hidden possibly downsample limit of 600 dpi bug: Aha: the .afpub file size increases from 96 to 124 MB, simply by changing frame sizes, though APub saved all content anyway even before. – Buggy bug. But more relevant in the screenshot above: the exported PDf now has 90 MB (towards 59,7 before) - whereas it contains data of about simply 1.8 MB, as the jpg-export from pdf confirms. Finally, here's a visual comparison of files highlighted in the screenshot above: Left: 1.8 MB exported jpg from PDF – Right: the original APub exported PDf with 90 MB: @Martin, now I do know what I wanted to know. Hard stuff. Thank you! –The rest is up to Serif ...

Doesn't the "Symbols" panel enable what you want, as long you toggle in time with its "Sync"-button?

Martin, I am still shure it can be done in Affinity, since you was able to create the layout document already. The minimal output size of JPGs is neither related to a layout documents file size nor to the file size of its linked or embedded JPGs. In this matter there is no difference to Indesign. But for now there apparently occure two main errors in a.) your export result and b.) your document, which should get avoided before a final judge: a.) The lack of an impact of jpg compression rate on export: b.) The difference in document file size towards the sum of its placed files sizes. I do not know if b.) has an influence on a.), because I do not understand yet what happens to your .afpub in b.). But actually/indeed the exported size is independent of the document size. Think of the export as a digital version of a printed photocopy that can have little or much in common with the original. Only if the original is upscaled during export, the output may appear increased relative to the input (but with reduced quality). c.) I suspect a third issue in the negative impact of the newer pdf version 1.7 towards 1.4 and 1.3 – but for the moment I'd ignore this for several reasons. So, again, I want to 'invite' you to upload an .afpub with one averaged page of your entire doc, might be in DropBox or any other (free) cloud. Or do yourself one more test as described in my last post. This may suite to discover details or solve issues. Don't throw in the towel, since you have gone so far. p.s.: did you do a "Save as..." with your .afpub yet? As in InDesign it appears to possibly clean up and get rid of data garbage.

Yes, that could be a use for this. – e.g.: I work in a 300 pages book on page 48 and just jump for a second to page 220 to check a wording. And to jump back from p.220 I do not have to remember the 48 because I can read it in the lower left corner and so I scroll + click in the pages panel to come back to the active page so easily thanks this understanding of "current"? Yes, this might be possible. However, back to the topic: but to export the "current" page does not have this in mind, does it?

"And let that be a lesson to you" ;•) https://xkcd.com/1994/ If Randal knows Greg ...? https://www.funbrain.com/books/diary-of-a-wimpy-kid/page/6

For macOS: If you have installed them on your mac yet then they (should) appear in the profile pulldown menu of export options. No need to "import" them to APub. If you haven't them in your system yet put them into /Library/ColorSync/Profiles.

Ah, I guess I got it know. Thank you for patience! – I have thought it would be kaputt here because I understood "current" and "active" to be related to me and my current action. In the meaning of "present", "actual", "relevant", "of that time" ... But "current" here also can be related to a page which I recently used but do not use anymore because I am scrolling through the pages and e.g. reading on another else. That is sort of unusual understanding of "active" and "current", imho. This morning I took the bus 57, then I left it and went for a walk. – So I wonder now: Is bus 57 still my current location? Can you possibly try to explain for which usage this understanding of "current" is created in AFPub? How can I use it? The print option could also use the main window page or the gray marked spread in pages panel as "current", right?