Dybkjær

Create a new document in Publisher 2.3.1 and press Import Styles..., Publisher crashes immediately. Beta 2.4 works, no crash, even with the same document as the one created and crashing in 2.3.1. So likely not high priority, but still. Document example enclosed. The text box is not important, it crashes both before and after saving the document or adding a text box. crashtest.afpub

Thanks. Yes, I see it. A simpler solution to the adjustment. Still, the glitch is an error, but I'll have your approach in mind next time I do this sort of thing.

Hi Hangman, that also seems to work. What did you do the to document? The adjustment layer and the 50 % opacity still seem to be there. In my original document I ended up replacing the 50 % opacity with 100 % opacity and increasing the luminance (in HSL colour view) to match what it was. That has the added advantage of removing some transparency, something PDF tends to get wrong when printed, even if the PDF looks ok on-screen.

I can see it works, but why?

Affinity Designer 2.1 and 2.2.0 2005 beta (help says: 2.2 eb0ee), on iPad Pro 12.9 sixth generation, iPadOS 16.6.1. A transparent png with a filter on a background with reduced opacity (e.g. 50 %) will darken the background within the bounding box of the png when exported to pdf. See the two screen shots below (cropped). The rightmost one is from the pdf and has a darker area in the transparent part of the png: The enclosed zip file has 7 files with reduced complexity with only one page with two objects (extracted from a 144 page book with several of those glitches in seemingly random places). The files with suffix beta are pdf's generated by the beta version. The other pdf files are generated with AP 2.1. The three original files: 1. filter-opacity-pdf-glitch.afpub: Reduced original that exhibits the export glitch. It has a png with an adjustment filter on top of a blue background with partial opacity. 2. opacity-pdf-glitch.afpub: Without the png adjustment filter. Produces no glitch. 3. filter-pdf-glitch.afpub: With full opacity of the background. Produces no glitch. As for other pdf generation errors, there are workarounds (e.g. produce the colour levels without opacity reduction), but they are quite cumbersome and troublesome to first detect, and next figure out. Best regards, Hans PS: The example glitch is pretty light. One may obtain much darker contrast glitches. pdf-png-glitch.zip

Yes, the bug isn't stable. However, I want AP to be predictable here, not tweakable. Select same fill colour selects both objects, yet the left one gets miscoloured. Copy the right object, paste style on the left, still it gets miscoloured. My current workaround fix is: Duplicate the ok object. Change corner cordinates to those of the not-ok object. Delete the not-ok object. Now the image looks the exact same in AP, and works when exported (no miscoloured objects).

This is about PDF export from Affinity Publisher. Tested with AP 2.1 and AP 2.2 b6711, iPadOS 16.6, iPad Pro 12.6 (6th generation). I have two objects, seemingly the same colour (left). When saving as PDF (for print) (vanilla settings), one gets a wrong colour for one of the objects: I enclose the original afpub file and the exported pdf. As this is for a soon-to-be-published book with many occurrences of this bug, I hope it will be fixed soon. Best regards, Hans colourtest.pdf colourtest.afpub

I know this is old, but: On both iPad and Mac, Pages has a wonderful option of writing equations in TeX (LaTeX):

I've now described it here:

I use iPad Pro 2020 12.9", iPadOS 16.5.1 ("is up to date"). In the enclosed spelltest.afpub I have duplicated a Frame text box, and language is UK English: I change that to German, and the wiggly lines disappear in the selected box: I apply the style change: But the rightmost box still has wiggly lines: Doing the above with other properties, such as bold, takes effect immediately on update style, both boxes become bold: Only if somehow do extra operations on the boxes, e.g. exit the document: and then re-enter: Now the text has no wiggly lines in any of the boxes: Severity: It has an easy work-around. On the other hand, I wasted quite some time believing "language" was not part of the style, and manually updating and applying language to the individual boxes. Extra note: In the final picture, "That is German" does not have wiggly lines. You could have fooled me into thinking "That is German" is English and not German, and hence should have wiggly lines. Indeed, if I change the first line into Danish, it has wiggly lines when choosing German spelling: I see the same effect in Pages, though, so this extra oddity seems not to be Publisher, but either Apple spelling or some setting on my computer. spelltest.afpub

It confused me, because when I changed the language, it didn't seem to take effect in neighbour boxes with the same text style. In this picture, they should both have had the red squiggle as they have the same, updated text style (updated while the left one had focus): However, when closing and opening the document, it takes effect. This in contrast to e.g. changing to a bold font, which takes effect in all boxes in the moment the text style is updated. So I concluded a bit too early, based on this difference in effectuation time. Thank you for your help.

Thanks, that is really helpful. It seems that this property does not count as part of the current style? In contrast with the character styles it is grouped with. Luckily, it seems to work when selecting all 1500 text boxes and apply Danish at one. Not via ctl-a which only works on the current spread (good), but via drag-select which can select across spreads. Spelling->Learn (from the upper left sandwich button) does not seem to work. When I press "Spelling", "Find", and then "Learn", and exit the box, it is still wiggly·

Which makes the wrong spell checking much less annoying. Now we only miss the ability to do spell checking in the language we write. Sometimes it is English, aber ab und zu ist es Deutch, eller som for det meste, dansk.

I wholeheartedly support this. Dark themes are inherently low contrast. You don't even have to be visually impaired in order to have trouble, my 60-years old eyes are fairly standard, and yet the poor choice of dark theme hampers the use of Publisher/Designer/Photo (currently I mostly use Publisher). This is a problem in Publisher 2. Just checked the newest Designer 2 Beta, and still no fix there. For reference, please se the sample image from the assets.

Agreed, it is really weird that they stick to the hopeless "we want you to guess what you are doing" dark theme on iPad.