anweid

This is a slightly edited copy of my post from 2019-12-06. The problem still persists with Affinity Publisher 1.9.0.920 (Windows): Bulleted lists can easily be created with custom bullets. With a dedicated character style, it is even possible to make the bullets very large and position them much below the baseline, without changing the leading of the 'real' text. Wonderful. The video uses a 10pt font, and the hand bullets are 40pt with a baseline offset of 14pt. This is exactly how it should look. Fine. But when selecting some text in this bulleted paragraph, the selection marker itself vertically extends from descender to ascender of the very large bullet (instead of the selected text), which is rather confusing. The text cursor nearly always has the correct size, but is too large at the beginning, where it again becomes as large as the bullet settings, which is confusing. It would be nicer if selection and cursor sizes would only extend to the dimensions of the text itself, not taking the bullet settings into account. Andreas Weidner largeselection.mp4

This is a copy of my post from 2019-12-06. The problem still persists with Affinity Publisher 1.9.0.920 (Windows): Affinity Publisher 1.8.0.502 (and previous versions) can automatically capitalise the first character in sentences. In order not to capitalise behind abbreviations, a list of common abbreviations is supplied. Fine. Unfortunately, the detection of the end of a sentence without abbreviations is more unreliable than with other programs: Apparently, Publisher not only looks at the last character entered and checks for end characters like '.!?' and such, but also at other characters before that, resulting in unwanted capitalisation. In all following examples, the second part of the sentence was wrongly capitalised, because Publisher finds an exclamation mark somewhere, but fails to realise that there are other characters between the exclamation mark and the rest of the sentence: He cried “Help!”, But nobody came. But - alas! - It was not so. Aged 104 (sic!), She began to play the piano. It would be nicer if Publisher only looked at the last entered character and derived the end-of-sentence information from that, instead of looking at lots of other characters. Andreas Weidner PS: Mind that the second example uses hyphens, which are typographically nonsense there. With the correct n-dashes, the second part of the sentence is not wrongly capitalised...

What a pity – I hoped that it was something that I just overlooked... Thanks for the idea of embedding. At the moment, though, I just made finishing touches to the assets and will import them into the other Affinities and hope that the assets won't change soon... Andreas Weidner

This looks as if the first fit was calculated with the window's client area while the scroll bars are visible, and only the second one takes into account that the scroll bars should not be visible... Andreas Weidner

Ah, I see. An 'unclosed cat'... The inside/outside arc problem still persists in version 1.9.0.911, but with a closed shape it depends on whether or not the contour is positive or negative. Even though you have already logged that bug, look at 0:06 and 0:12 of the video just in case, so you can see the two different behaviours. Andreas Weidner catcontour2.mp4

Affinity Designer 1.9.0.903 for Windows behaves as illustrated in the attached video (3 strange things): Draw a cat with your funny cat tool (which even draws a different one in Photo). Apply a contour and slowly increase the contour radius. At first, everything looks logical. At 0:09, one of the contour arcs snaps to the inside of the contour. At 0:14, it correctly snaps to the outside again. The inside snapping appears to be a bug. At 0:17, a small artefact appears at the right hind foot. At 0:22, a second one appears. At 0:37, a lot of of weird things start to happen until everything looks rather psychedelic at the end. This appears to be a limitation of the used algorithm and probably does not need to be corrected – nobody would want to equip anything with such a ridiculously wide contour, anyway. But take a look at the cat's neck: This is probably where the outline starts, and it seems to start and end with different slopes, creating a sharp groove at the inside of the contour, which doesn't look so nice. I would suggest that, in case an outline's start and end points do not have continuous slopes, to equip the contour not with a sharp groove, but either a straight line or a circular arc between the current contour's 'groove points'. Since this description might be completely incomprehensible: In the attached picture, the red area might be added to the contour, so that the groove vanishes, and everything looks smoother. Andreas Weidner catcontour.mp4

I would like to use one category containing lots of assets in all three Affinity applications. The assets were created in Designer, but should also be used in Photo and Publisher. Unfortunately, I don't know how to do that: The asset category shows up in Designer, but nowhere else. Though it is easy to export the category in Designer and import it into the other programs, this creates independent copies of the original category. Changes in one of these copies are not reflected in the others. I would therefore have to administrate three independent categories and hope that I properly keep them identical. That's a lot of work and rather error-prone. Is there any possibility to share the same category between all Affinity programs, so that changes in that category are automatically reflected in all other 'Affinities' (on the same computer)? Andreas Weidner

Affinity Publisher 1.9.0.902 for Windows has the possibility of PDF passthrough, which is wonderful. Unfortunately, this does not work in conjunction with clipping: Every PDF containing vectors seems to work nicely together with every affine transformation (rotate, shear, scale): The resulting PDF file still contains vectors. Fine. As soon as I do a vector clip with Publisher in order to throw away unwanted things (e.g., a footer with page number), the resulting PDF will be rasterised and not contain any vectors anymore. Additionally, Publisher does not warn during export that anything will be rasterised: The export dialog explicitly tells me that nothing will be rasterised. The only hint I get is the suspiciously large size of the exported document. This happens with every clip, even in case only whitespace is clipped away, or if only 0.1mm is clipped away. As far as I know, PDF supports nested clipping paths. It would therefore be nice if PDF passthroughs could be clipped while preserving their vector structure. If this by some reason isn't possible, it would be useful if the export dialog would at least warn that something will be rasterised. Andreas Weidner

No, they don't. Apparently the forum realises that the images contain nothing but a white area and just refuses to offer them in the GUI (they only appear for me while editing my own post). Anyway: At the colleague's PC, Affinity's display screws up the colours - the images themselves seem to be OK and are also saved correctly... Andreas Weidner

Good idea, let's try. With a little bit of luck, they'll appear...

Hmmm. The display of above message in the forum is also quite fishy: It only shows the large screenshot and the *afphoto file, but not the small PNG and JPG files. When trying to edit the message myself again, they are shown properly. If by some reason the smallish files are not accessible, I could also send them via e-mail... Andreas Weidner

I'm writing on behalf of a colleague who downloaded the 'Affinity Photo' test version today, because I recommended the software. Since his English is not so good, I'm doing the writing... Unfortunately, Affinity Photo for Windows does not work decently for him, because the colours are screwed up. All other programs (including PhotoShop Elements) display them correctly. The following happens: If I create a new *.afphoto file with a white background, white is correctly displayed as white. Such files are always displayed correctly. Now I export this file as PNG and open it in a separate window. The white appears extremely yellowish. I export the *.afphoto as JPG and open that. The white is yellow again. This colour problem appears with all image types from all sources we tried but *.afphoto, even when just getting a screenshot from the clipboard using 'New file from clipboard'. The colour picker tells me '255,255,255' for all the images, even the distinctly yellow ones. He does not use any colour profile or colour correction on his PC. All files are attached. The large PNG file with the screenshot was not saved with Affinity Photo, but IrfanView, because using it with Affinity makes it yellowish again (which would result in 'yellowish-squared' at some places). The screenshot also shows the global colour settings, which are the default ones, and which up to now always worked properly on all other PCs. Whatever I tried remotely with colour profiles and whatnots only achieved slight display changes, but did not remedy the gross colour aberrations. I could not find a way to persuade Affinity Photo to globally ignore colour correction... My own PC displays all files correctly. Do you have any suggestion how to solve this? Thanks. With best regards, Andreas Weidner 100x100-AffinityOriginal.afphoto

Just for reference: The official version 1.8.2.620 again crashes at trying to load the document.

Done. I copied the fonts that Publisher shows in its font manager. You probably have 'Symbol' and 'Wingdings' already installed, anyway. The rest should be either bought, self-made or both... And: If you write 'to investigate the layout issues', does that mean that the document can now be loaded without crashing, so that you are able to detect 'layout issues'? With best regards, Andreas Weidner

Done. Inside the ZIP file, you'll find EAGLEInANutshell.afpub (plus hopefully all necessary images), which I'm in the process of updating from an old InDesign document (not imported as IDML, but newly created from scratch and using copy-and-paste) to a new version with Affinity (currently, Affinity is still missing some functionality). The corresponding PDF file was created with version 1.7.3.481 and shows how the document should look like. The document gets messier the farther one gets to its end, and for the time being, I did not include the fonts, so please don't get a shock when seeing it. If for some reason, you need the fonts, I can also provide them via DropBox (would that be the same link, or a different one?). With best regards, Andreas Weidner PS: Even in the PDF file, the main font looks rather strange. This is due to extremely bad kerning of that font, which I'm also in the process of updating...

A rather complex document (50 pages, several linked images, lots of pins, table of contents, index) created with Affinity Publisher 1.7.3.481 just refuses to work properly with any later version: The beta versions 1.8.x prior to the official version 1.8.0 are able to load the document nicely, but always crash reliably on trying to either update the table of contents, or doing a preflight check. The official version 1.8.0 utterly fails to load the document, and always crashes reliably when trying to load it. The new beta version 1.8.2.619 reverts to the 'old' behaviour: It can read the document, but always crashes on updating the table of contents or doing a preflight check. Therefore, I reverted to the old version 1.7.3.481 again, ignored the current official one, and stopped using Publisher for the time being (which is sad), until a bug fix is available... Since the problematic document is currently not for public distribution, it would be useful to get the possibility for a private upload or something - thanks. With best regards, Andreas Weidner

In Affinity Photo 1.8.0.555, it works. Wonderful - thanks. Andreas Weidner

The German Affinity Publisher 1.8.0.502 shows the following two small bugs when trying to add index entries: Nothing is selected, the Index studio is not active (0:00). If you now go into the text and activate the Index studio, the Add marker button stays disabled, even though the text cursor is located at a point that should allow an index marker (0:02-0:09). Only after moving the cursor somewhere else and back again is adding a marker possible (0:09-0:21). The Topic name edit field of the Add index marker dialog allows pasting text from the clipboard, which is nice. Unfortunately, text is pasted including paragraph formatting here, which seems strange: In (0:22-0:36), I select the word list in the bulleted paragraph, copy it to the clipboard, open the Add marker dialog and paste from clipboard, which not only pastes the word 'list', but '• list' (meaning <bullet><space><space>list). The same is valid for (0:40-0:55), where the word list copies from the numbered paragraph is pasted including the numbering. It would be nicer if the Add marker button would be correctly enabled/disabled when the Index studio gets activated, and if pasting inside the Topic name field would strip paragraph formatting. index.mp4

Affinity Publisher 1.8.0.502 (and previous versions) can automatically capitalise the first character in sentences. In order not to capitalise behind abbreviations, a list of common abbreviations is supplied. Fine. Unfortunately, the detection of the end of a sentence without abbreviations is more unreliable than with other programs: Apparently, Publisher not only looks at the last character entered and checks for end characters like '.!?' and such, but also at other characters before that, resulting in unwanted capitalisation. In all following examples, the second part of the sentence was wrongly capitalised, because Publisher finds an exclamation mark somewhere, but fails to realise that there are other characters between the exclamation mark and the rest of the sentence: He cried “Help!”, But nobody came. But - alas! - It was not so. Aged 104 (sic!), She began to play the piano. It would be nicer if Publisher only looked at the last entered character and derived the end-of-sentence information from that, instead of looking at lots of other characters. Andreas Weidner PS: Mind that the second example uses hyphens, which are typographically nonsense there. With the correct n-dashes, the second part of the sentence is not capitalised...

The German Affinity Publisher 1.8.0.502 (and previous version) behaves as follows (see video): The image is pinned to a paragraph that is automatically numbered. The pin is located somewhere inside the paragraph. Everything is OK. As soon as the pin position is moved to the beginning of the paragraph, the automatically created numbering of the paragraph changes size. Moving the pin position back into the middle of the paragraph also restores the correct numbering format. Attached is an edited version of the original document to reduce file size... Andreas Weidner PinNumbering.afpub PinNumbering.mp4

This is what happens: When opening the PDF file in Publisher (not placing), it shows a PDF options dialog on import, where the (really small) page preview more or less exactly shows the correct page layout (see screenshot 1). But Publisher apparently wants to make texts editable and complains about missing fonts, which it either wants to replace or not. Whether or not I choose this option doesn't really matter, because both result in destroyed text and layout (see screenshot 2). It would be nice if a PDF page could just be opened/placed as a single entity (not necessarily editable) that looks more or less exactly like the original. If this is what you mean with the words PDF pass through, then that seems to be it. PagePlus X9 (and not X8 as I claimed before) apparently does that as follows: On PDF opening, I can either use the embedded fonts, or replace them by something else. Any of these creates an editable document, and the option with the embedded fonts looks quite good on first glance. On PDF placing, an image is shown that looks exactly as the original PDF (no questions are asked). And now I realise that if I select this image, an option called PDF-Passthrough is shown in the toolbar. So yes, apparently I would very much like to import such files with such a PDF passthrough... Andreas Weidner

The German Affinity Publisher 1.8.0.502 (and previous versions) fails to properly import the attached PDF file, which mainly consists of one page of text: The font and all character positions are wrong. All PDF viewers I tried can properly display the file, and PagePlus X8 also properly imports it. Andreas Weidner 1MHzCheck4-partlist.pdf

The German Affinity Publisher 1.8.0.502 (and previous versions) behaves as follows: Bulleted lists can easily be created with custom bullets. With a dedicated character style, it is even possible to make the bullets very large and position them much below the baseline, without changing the leading of the 'real' text. Wonderful. The attached screenshot uses a 10pt font, and the hand bullets are 40pt with a baseline offset of 14pt. This is exactly how it should look. Fine. But when selecting some text in this bulleted paragraph, the selection marker itself vertically extends from descender to ascender of the very large bullet (instead of the selected text), which is rather confusing. In the screenshot, the word 'the' is currently selected. It would be nicer if the selection would only extend to the dimensions of the selected text itself. Andreas Weidner

Ah, that's a good idea - thanks. I still think that the mentioned behaviour is a bug, but at least this workaround helps me to continue writing for the moment. Andreas Weidner

This also happens in version 1.8.0.502, which I just found...