jakamaschi

Thank you very much for your comments . This makes the results of the regular expression clear to me. I don't know whether my view is globally correct, but my understanding is that each table cell is a self-contained unit. Is it possible that this will be implemented in the future? But I am afraid that this will be too much effort ... The problem with my text is that I didn't insert the unwanted spaces, I just have to correct them ... 😞

I select the cells of a table column and go to the "Find and Replace" panel (or press <apple-cmd>F). In the options dialog for "Search" I select "Regular expression". It makes no difference which "Regular expression option" is checked or unchecked, especially the "one line mode" option. I have attached a screenshot of my search settings. Unfortunately it does not work to include the options dialog. If the leading caret is removed, the desired but also the unwanted spaces are found. It seems that the beginning of a text in a cell is not recognized as the beginning of a line or paragraph by the regular expression.

I am trying to use a regular expression on a table to delete a leading space in (nearly) each cell (the first letter are always capitals). But ^\s([A-Z]) does not find anything . Without the caret the spaces are found, but also many desired spaces. Does the caret not work for line/sentence start in tables?

The missing cross-references feature (at least to page numbers) is also a feature i want for. Sorry, the 'hack' with the linked text-frames is not a practicable solution ...

Thank's for your reply. I had uploaded the request files. with regards

I have problems with a set of fonts (Linotype Agfa Sans Serif) with Publisher 1.8.6 running on Catalina (10.15.7). The OS X info panel marked them as 'Postscript Type 1 Konturschrift' (Kontur german for outline) The Glyph panel doesn't show any glyph, Publisher itself show all glyphs in the text frame, but certain glyphs (for example '½') are not exported into PDFs (white space), while the common glyphs A, a, even Umlaut a etc. are exported. When i opened the font panel under Document, the font is listed and marked as OK. I checked the fonts with the font tool of OS X: all glyphs are shown, checking the font gives no warning, every topic is green (ok). When using Pages all glyphs are exported into PDF. Therefore i'm sure that the fonts itself are not corrupted. I attached the PDF output of a test and the corresponding screenshot of Publisher. with regards font_test.pdf

i converted the color space from RGB to CYMK and reduce the size of some images to a fix width of 600px. But i saw, that my estimation of the amount of images was too low, i linked 325 images to the document. I could apply the changes to the document by opening the document, and overwriting approx. twenty images at one time with the new version, then go to the resource manager select the images that where marked as changed and press "Aktualisieren" (i use the german version). After doing this with all images, everything was ok. Therefore i guess, it was not the kind of changes but the number of changes that crashed the program. By the way: instead showing a small window for _every_ resource that was recognized as altered outside Publisher, it would be more comfortable to show only one dialog with a list of all items. Or give only a warning and ask to open the resource manager directly.

i have a document containing approx. 180 images (all linked). After changing all images with an external tool, Publisher 1.7.3 crashes when loading the document. There are lots of warnings that a resource had been changed. There is no crash, if the images are changed batch-wise, like 20-30 images per run. crash_report.rtf

Thanks, that saved my day!

I edit a Affinität Publisher document together with a friend. He work on the text-part, i on the image part. All images are linked and stored in one folder beside the Publisher document. But since Publisher stored the absolute path to the images an exchange of the Publisher document is not really practicable, since the absolute paths on each computer are not the same. Therefore after exchanging the document, both get the warning of missing resources and have to replace every(!) image manually inside the Resource manager. Since we have several dozens of images in our document, every time a laboriously, painstaking and error-prone job. My question: is it not possible to change the path to all linked images with only one single change of the path to the folder? Or to use a relative path to the images, relative to the Publisher document. Or a tiny, little bit of AI inside the resource manager to search for the missing images, after one had manually exchange the first missing image and therefore giving a new path to the images?

I am unable to open the document i created with the previous beta version, the program immediately crashes. Is the document format of this beta version incompatible to the old one?