thomaso

Unfortunately the crash on Save-As with same file name came back to me. It just occurred with a new created .afpub in v.1.7.2 – (just 8 pages, text flow, a few rectangles). v172 text flow with masters.afpub The further conditions are the same as described in this previous thread (which seemed to be solved with beta v.458):

Bad news: the issue with crash on Save-As with same file name is back to me. It just happened to a new .afpub created from scratch in v1.7.2. (not complex: eight pages, just text and a few rectangles / 2.1 MB)

@Thomas, you had tagged this topic to be "reproducible" – but I am not able to make the issue of duplicated text and weird text selection position occur in a test file. v172 text flow with masters.afpub So I assume the reason for iusses in your .afpub could be related to that specific content, for instance the way how the text came into your document and the way the layout was created. For inspection: Could you upload the document, possibly only a few pages and not embedded images, and/or with different text in case yours should not become public yet? Or: do you get the same issues if you paste your text into my sample .afpub?

Is there any reason you add it to the application package file instead to the according preference folders? ~/Library/Spelling/... ~/Library/Dictionaries/... ... <– subfolder with a name in the format xx_XX (ie nl_NL) 

• I never entered the = , and I have not experienced a calculation that did not work. • Make sure to keep a space before (or after) your entry and the existing. • Ignore and don't type the unit, unless you want to make a calculation in a different unit than your current unit.

I experience a bug vice versa: • Changing margins of a master page successfully transfers this change to the according document pages immediately. Fine so far. But ...: • "Retrieve Margins from Printer" results in weird margins. (... as it did before with any AfPub's beta). Printer & document page size are A4 (210 x 297 mm). The printer works well with a margin of 5 mm. I wonder where AfPub retrieves these margins from; they are not from the installed and selected printer. p.s.: actually this issue does not influence my workflow since I can use my default 5 mm and get them reminded by AfPub for new documents even without saving as a preset. In addition, I assume that such a theoretical printer margin is often larger than the real technical + practical printer margin - and therefore all "retrieved" values might differ from what is desired and get set manually anyway.

The initially chosen document page size appears numerically always as default size when creating a new master page. This size is also used for new document pages - regardless of selected any or None master page for it. That would force to choose a master page when creating a new document page. Yes. I guess no one yet has recognized the use/goal of the way master pages can become assigned to document pages without assigning their size, too. This feature might be "by Design" but I can't imagine it is designed in purpose. Possibly it is just a workaround around the conflict when various master pages get assigned to a document page: whereas this masters may have different sizes the document page must have 1 only – and therefore it appears the easiest to ignore all the masters sizes. This way master pages are not pages actually but rather margin settings (page size independent !) + object containers (which appear as Master page layer on document pages). It is interesting but also makes me doubt about "by Design" that I may move, rotate, scale, stretch and shear a complete Master page layer on a document page without the need to detach – whereas I need to detach it to change one single object color for instance. At the moment I still have the impression that this way of master page handling is very helpful to create chaotic documents with chaotic layouts in quite a short time. Could help develop a new level of typography ... David Carson 2.0.

Wieviele .ai Dateien hast du denn bisher zu öffnen versucht, dass du dich veranlasst siehst zu schreiben, dass du keine Datei dieses Typs öffnen kannst? Deine Beispiel-.ai-Datei enthält keine Objekte, sondern nur Hilfslinien. Um den Inhalt dieser Datei in AfPublisher zu erhalten, kannst du alternativ AfPub's Hilfslinien-Manager verwenden.

Just as a reminder: this issue still occurs in the retail v408 and beta v458, too. I just got reminded to it by this different but similar weird issue on DPI change in AfDesigner: https://forum.affinity.serif.com/index.php?/topic/39554-ad-why-does-changing-document-dpi-change-rounded-corner-sizes/&amp;do=findComment&amp;comment=510219

Its visibilty appears to vary with the zoom level. text instertion marker.mov As a workaround on empty lines a double-click highlights the cursor position:

Another reason for this unspecified error message on PDF export can be font issues. You can try to either use a different font or convert the text to curves BEFORE export to detect whether its font related.

I want to add a suggestion: 3. In the TOC sidebar highlight the chapter which is currently shown in the mac help.app main window. In particular if you got jumped to an article by using the Affinity help menu it can be hard to find where this article belongs to. Therefore it would also support the understanding if the according item in the sidebar would become unfolded in case it is hidden in a level below a main topic. 4. I experience since the retail version v408 this help.app I can't get the search results > articles opened in the Affinity app language but mostly in the system language, I could not detect a rule yet for that language choice of the help.app. Even though I can search in a different language the results are shown in system language only. This behavior was different and more useful in beta versions before v408. Whereas I can switch the language in the online help I don't have this option in the macs help.app.

I also experience this bug and its necessary workaround in beta v458. Regardless of the exported PDF version v1.7 preset for print + PDF/X-3.

One reason could be that such an imposed page order is necessary and useful for print only. No one would/could read an imposed PDF. So imposition is part of the application which starts the print process, therefore it also is able to respect the paper size and according margins – which would not be included in same flexibility if saved in a PDF.

Is not this a setting in macOS for 8 years? http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion/