lacerto

January 20

13 hours ago, charlesbewlay said:

Lacerto, I'm gobsmacked!!! How can I ever thank you enough?? The other paras are a relatively easy fix. I'll sleep better tonight.

You're welcome. I am happy to be able to help, and always learn something myself, too! In addition to Pages, I found LibreOffice very useful, too, it could be used to accept all revision marks and stop tracking, though I am not sure that the results were expected (as it also accepted deletions, which possibly were not intentional -- I suppose tracking was actually left on inadvertently, when preparing a version just for the forum review). UPDATE: LibreOffice would also support indexes and most other Word features and would therefore probably be the best tool to fix corrupted Word documents.

It was really odd that Pages could do numbering so well -- as you mentioned Pages yourself, could it be that the text was at some point in Pages???

I wish you get it sorted out -- it is not a small task to learn to use new tools, even if much might be familiar from other similar apps!

January 20

5 minutes ago, iconoclast said:

because this is a well ordered and reliable workflow, that prevents needless problems.

We have done DTP for decades and practically never do it like this. We typically import cleaned Word documents (images etc. stripped) keeping local formatting and unifying everything else (basically using a single font and size when applicable) and then tag paragraph styles which we apply in layout with own scripts, using already defined InDesign formatting. This means that we would normally discard list formatting but might make an exception if the text has very complex hierarchy

When working with multi-language texts, sometimes including RTL ones, with legal texts containing huge amount of footnotes, scientific texts containing equations, etc., normally with hectic schedules, there is really no alternative for us, and this workflow has never broken or caused any serious issues.

The document included in this post was somehow corrupted and would ideally require some fixes and preparation before being imported in layout, but as was shown, it was not so badly damaged that it could not be used even as it is.

But everyone with years of experience in publishing business has of course their personal preferences and optimized workflows they want to use whenever possible.

charlesbewlay · January 20

An afterthought: This was a really interesting problem because Apple Pages could basically fix issues with a broken Word (its ability to autoaccept table changes and control so well Word tracking is a powerful feature and makes Pages a valuable Word document tool). It is also interesting that it seemed to be able to handle numbered paragraphs so well. Without having the original Word document, it is difficult to say what actually caused the numbering chaos in Publisher (e.g., losing the number formatting). As mentioned, InDesign imported the sample Word document better but it was necessary to redefine the heading styles there, too. Yet the .docx file exported by Pages appeared to behave correctly in Word.

EDIT: I forgot to mention that I seem to have found a bug in the UI of macOS Publisher when trying to Find Replace heading styles. When there are lots of styles, it is not possible to scroll hidden styles visible similarly as it is on Windows where there is an arrow at the bottom of the list and where the mouse wheel can also be used to scroll these kinds of lists. I could not find an alternative method of having formatting style added in Find and Replace boxes so I did this task in the Windows version.

EDIT: I realized that it is possible to use arrow keys but it is of course pretty awkward...

UPDATE: Actually LibreOffice Writer could also be used to fix the Word document [accept all changes and stop tracking] and when saved back to Word format, the numbering problem was also fixed [but only when importing to e.g. InDesign; Affinity Publisher appears to have bugs in importing lists]. There was List Paragraph style that had alphabetical list style removing of which fixed the insanely long lists in a snap, but there are probably paragraphs where this list styling was intentionally applied so careful revision job is needed to make this document work as expected.

January 20

It is interesting that Pages seems to be able to handle the cleaned Word file just fine -- see attached the PDF that I exported from Pages.

Sample UNDERSTANDING COMMS FINAL GALLEY PROOF.pdf

However, if I try to import in Publisher, I get oddly messed up heading numberings, numbered paragraphs, etc.

If I import in InDesign, results are better but not nearly the same as in Pages.

UPDATE: I looked at the second Publisher sample you posted, and its heading numbering is incorrect, so the paragraph styles should be defined to have numbered lists with correct levels, and then the existing style assignments should be reapplied to get numbering right.

UPDATE2: I fixed the major heading numbering styles (heading 1, heading 2 and heading 3) and automatically reapplied styles by using Find Replace (searching heading 1, and replacing with the same style, etc.):

Sample 2 BOCRA Pages_fixed.afpub

But there are many lists that still need to be fixed, not just numbering but also formatting.

Note that you can restart numbering from the currently selected paragraph by using the option in the Paragraph panel:

January 20

I had a look on the Word document that you posted, and when I tried to accept changes and stop tracking, Word stops responding. The same happens also on macOS Word, and LibreOffice Writer cannot handle the file, either.

But I took it to Apple's Pages, which auto-accepted all tracking changes in tables and other places where it cannot do tracking, and then I accepted manually all changes in Pages, and removed also comments. You can find attached a cleaned file. I suggest that you do the same process yourself (Pages is free app on App Store) to see that what Pages does is correct. [EDIT: It does not seem so, so the original document might just be corrupt, and require manual cleaning.]

Anyway, when I imported the cleaned document in Publisher, the style nightmare seems to be over.

Sample UNDERSTANDING COMMS FINAL GALLEY PROOF_cleaned.docx

January 20

I downloaded your Word file and it has revision marks, which Affinity Publisher reads in. You should accept all revisions (on the Review tab) and stop tracking and then import the cleaned file:

(Again, this is probably a bit different on macOS.)

Note that Publisher also imports all hidden text so if you have obsolete styles there, these styles would also be imported.

January 20

1 hour ago, charlesbewlay said:

I've been deleting all Publisher styles before importing for a good while now: a lesson early learnt.

Ok, fine. Have you checked if your document contains obsolete (old but not currently used) style definitions as Publisher might import all styles whether used or not [the screenshot is from Windows version but you should have something like this also on macOS version]:

January 19

On 1/18/2024 at 10:49 PM, thomaso said:

which is strange again since the webkit-logo also uses this profile but fails in Firefox

This especially suggests that Firefox actually converts colors instead of just assigning a missing sRGB, whenever it needs to interpret the source color values or handle unmanaged files. IMO assigning sRGB would be more proper.

January 19

1 hour ago, ms.fuentecilla said:

I have put a pge number insertion in my Publisher file but they do not export with the pdf files

If you mean custom page numbering and its transportation to a PDF, this is not supported in Affinity apps. You need to use Adobe Acrobat Pro or similar utility to apply custom page numbering onto a PDF.

January 19

If your workflow is importing a Word document that is basically more or less fully style tagged, I would import that file in a Publisher document that has all default styles (not used) deleted. That would avoid having multiple styles with identical or nearly identical style names cluttered in the layout and confusing formatting of the document. Publisher does not have a capability to signal conflicting styles and let the user design at import time, whether to use Publisher-defined styles with the (matched/similar) style names, mapping the imported and existing styles, or overwriting Publisher styles with imported style definitions, and avoid what you describe as "style nightmare".

So if you have a good arrangement in Word already, I would recommend importing into a document that is as much as possible cleared of in-built styles.

EDIT: This would be a workable solution even if not having Word styles well-defined. Just having source text tagged with paragraph and character style names and finalizing the actual style definitions in Publisher, should work well. It is the style name conflicts that are probably the biggest nuisance in preparation of layout.

thomaso · January 19

22 minutes ago, thomaso said:

Visually the .ai example appears like a trapping result

Basically something similar though the overlap is much bigger of course and there are no things like overprinting etc. happening.

23 minutes ago, thomaso said:

Can you delete one and reposition the AD.png from the post bottom to avoid confusion?

It should be done now.

loukash · January 19

11 hours ago, NotMyFault said:

Seems this is an issue rarely having an noticeable impact as lacerto said.

I am not sure that I understand what you mean? It is noticeable whenever this kind of design is exported using certain apps, but as mentioned it does not necessarily show in print.

11 hours ago, NotMyFault said:

And there are easy workarounds.

It is much a question precisely about that: needing to work around, in lack of a feature. Some are easy, some less easy. Sometimes using an outer stroke is more convenient, I guess that's why strokes have three alignment types.

11 hours ago, NotMyFault said:

Interesting, do you have more details? Does it work for raster and vector export formats?

Illustrator, e.g., does it both when exporting to vectors (e.g. PDF, SVG), and when exporting to raster formats (e.g. PNG):

a) PDF and SVG (Illustrator vs. Affinity Designer):

b) PNG (Illustrator vs. Affinity Designer):

For vector graphics, Illustrator expands the outline and then overlaps the "stroke" and "fill" parts. For raster graphics, it uses supersampling to cover the antialiasing artifacts.

11 hours ago, NotMyFault said:

No matter which approach is used, it will definitely modify the original curve / stroke of the file. So if you export e.g. to svg and re-import again the layers will differ. I dont say this is a bad thing, but at least users should have a choice.

For me it is a question of „Philosophy“: Affinity apps tend to export layers „literally“.

Typically native objects need to be more or less modified when exporting to different vector formats, so it is not so much a question of "fidelity" but of compatibility, effectivity and usability (optionally embedding the native format or PDF stream additionally offers at least limited shareability). And users normally have several choices (in most apps). I cannot see "philosophy" here; something like that gets offered every now and then on this forum as a kind of an excuse for needing to do things "differently", which often just means using a workaround as long as a proper feature has not yet been developed.

thomaso · January 19

18 hours ago, thomaso said:

Your non-alpha png files confuse me: They are saved without the P3-Display profile and show the illustration quite subtle in sRGB.

Yes, I made a wrong conclusion, it is not the transparency (A-channel) that confuses Firefox, but it seems somehow having information only in R channel (G and B being all 255), so when having a P3 profile embedded, Firefox macOS (but not Windows) version fails to recognize the difference in red in all cases.

P3_pngs.zip

January 19

I think I might finally have (some kind of) and explanation.

The Firefox gfx.color_management settings are not properly documented, but it seems that on macOS the setting gfx.color_management.native_srgb, which by default has the value true (turned on), overrides the gfx.color_management.mode setting, and means that color management is handed over to the system:

The setting has possibly been added later for macOS, which means that users who have had Firefox installed for a long time, might not have this setting turned on (especially if the app has not been regularly updated). Anyway, when the value of this setting is true, Firefox on macOS behaves similarly as other browsers, meaning that unmanaged images will be rendered as sRGB. On Windows, this setting has no meaning and its default is false, so on Windows the same effect is achieved by setting the value of gfx.color_management.mode to 1 (which is NOT the default). On macOS this setting has no meaning if gfx.color_management.native_srgb is true. It should be noted that if the setting is changed, the system needs to be rebooted before it takes effect.

I do not think that this is what OP experienced, because macOS screenshots have embedded profiles. But when using Firefox, not having ICC profile support turned on, or having color management completely turned off (old defaults in Firefox), might -- depending on what kind of display is attached to the computer (internal or external, hw calibrated or not), and whether the profile embedded in screenshots accurately describes the display color gamut.

January 18

1 hour ago, thomaso said:

Oh, this examples make Firefox in comparison to Safari indeed confusing and not reliable.

Yes. What can I say: I just once again uninstalled macOS Firefox (and before that manually cleared the cache), reinstalled it, rebooted the computer, and now the default color management settings (mode = 2) work similarly for unmanaged images so revert to sRGB similarly as other browsers, so I no longer can reproduce the oversaturated images (with exactly same images) that I experienced yesterday (and demonstrated in one of my posts above).

So unreliable, to say the least. I do no longer wonder that OP managed to fix the issue by rebooting the computer! Anyway, I am pretty sure that this was a Firefox issue, and nothing to do with Affinity apps.

UPDATE: On Windows, at least, I can consistently switch the color mode between 1 and 2 and get the behavior described in Mozilla documentation (1 = color management on, revert unmanaged to sRGB; 2 = only manage tagged images) so that I know I have not just dreamt.

January 18

6 hours ago, thomaso said:

Do you still get this view – or was it fixed after your various trials / post updates?

It was fixed by setting the color mode to 1 (= general color management turned on; 2 = only manage tagged objects, which is the current default). This was specific to the situation of having unmanaged image (which OP probably did not initially have because the original image was a macOS screenshot).

The OP might have ICC v4 support off (or even all color management off), which would mean that screenshots with embedded profiles would not be color managed (but would show at full display gamut).

Firefox has been and is still in many ways a bit tricky with color management.

Proof:

https://webkit.org/blog-files/color-gamut/

Especially check the webkit red logo. I still cannot get any difference with Firefox, even after having made the setting changes but if the embedded profiles are v2, that might explain it (perhaps they are not supported in Firefox, at all so embedded profiles need to be v4). But all other browsers that I have tested work fine, both on macOS and Windows.

EDIT: This does work on Windows Firefox (with identical settings), but my Windows laptop is also ~Adobe RGB (has clearly wider gamut than my supposedly Display P3 MacBook Air display). But I will boot my mac and confirm. UPDATE: Now booted and retested, no difference whatsoever.

But I took the image webkit logo PNG (a 16-bit image) in Photoshop 2024 and saved it from there again to 8-bit and 16-bit images (Large file size) and both show in Firefox fine, so this might have something to do with image compression: Firefox does not seem to support certain PNG compression methods. UPDATE: This was wrong assumption, too. Photoshop saved versions were significantly smaller in size than the original version. Embedded color profiles are both by Apple so no difference there, either.

EDIT2: Finally resolved: Firefox macOS version cannot read profile tagged images that are 32- or 64-bit (PNGA images), so these two fail, but work without problems with other browsers (and all apps that I have tested):

pnga.zip

and when saved without transparency, work just well also on macOS Firefox:

png.zip

Hangman · January 18

Yes, on macOS there is an immediate crash already when selecting multiple layers (and having Vector Flood Fill Tool active).

On Windows there does not seem to be problems (which is good news, since there is probably just some blunder that messes this up on macOS):

January 18

Is there a specific setting you are using when applying the Flood Fill tool? I have been experimenting on these designs on a Windows computer and have not experienced any crash so far, but perhaps I am doing something differently. I have just randomly filled in shapes while having all layers selected, switching isertion and fill modes, clicking one shape at a time, or holding down for tens of seconds and filling continuously.

January 18

1 hour ago, loukash said:

Perhaps @bobdobbs should let us know which exact printer are they printing to?

Possibly. If borderless printing succeeded from within Publisher, then the same interface should be available also when printing from PDF (Adobe apps probably excluded). If nothing else works than at least creating an A4 sheet in Publisher (or whatever size is appropriate) and placing the produced PDF on the canvas to be passed through and print from within Publisher should work (as it did before).

January 18

6 minutes ago, loukash said:

The Preview.app print dialog should have access to the same printer features like the print dialog in Affinity.

Sorry, I was inaccurate. I meant the preview within Adobe Reader (and Acrobat Pro) -- I do not seem to be able to even access the Preview app from within these apps. I have no experience of modern printers supporting borderless printing and whether this feature could be accessed from generic printer UI (e.g. the renewed UI of latest Windows and macOS operating systems) but as far as Acrobat apps goes I suppose they communicate with printers more directly (but still might need access to printer driver to get specific information even if warn against this).

January 18

It is probably dependent on the printer, but it is possible (or even likely) that you need to access printer specific settings that enable borderless printing:

While I can still access these kinds of old printers even from within macOS Sonoma 14.2.1 (because they are attached to NAS), I cannot access printer driver specific special features like borderless printing without driver access, and it is possible that they cannot be accessed from within apps like Adobe Reader (or Acrobat Pro) without driver access even if using a modern printer supporting e.g. AirPrint. The preview window however often gives a realistic hint on whether borderless printing can be done or not.

thomaso · January 17

One further option that could be used in certain situations: temporarily hide the object(s) or object group(s) that you do not want to have effect on alignment:

UPDATE: Also works for snapping!

January 17

I had another look on this and did a fresh reinstallation of Firefox (which, as mentioned, nowadays has full color management by default enabled), and it seems that I was looking this from wrong angle: the app is color management wise simply just broken. When viewing the OP's ~~sRGB~~unmanaged screenshot taken from Designer (with a bit desaturated colors), Firefox is the only app not showing colors expectedly, but instead, too saturated (top left: Safari, TR: Photoshop 2024, BR: Affinity Designer, BL: Firefox):

I did not spend any more time with Firefox color management settings so they are what they are out of the box and appear to be as they should, ICC v4 profiles and color management mode 2 enabled. Perhaps someone knows if they should be something else but the ones used in latest Firefox version (121.0.1) and Sonoma 14.2.1 just do not work as they should.

UPDATE: I now tested this on Windows Firefox and the same behavior occurs there; it now begins to seem that this is intentional, so Firefox does not revert to sRGB, as do other browsers, if the viewed image is not color managed. I have thought that this is a universal practice and recommendation. Comparable policy is probably available within Firefox color management, too, but needs to be turned on.

UPDATE2: I could not get Firefox deal with unmanaged images getting them handled as sRGB (on neither platform) but it handles correctly images with embedded profiles. Setting the color mode to 1 resolves the issue (I earlier could make this mode operable only on Windows, but will check now its meaning and availability on macOS).

UPDATE3: It seems that there has been change in policy (and not even recent one) so that the default value of gfx.color_management.mode is now 2, which means that only tagged images are color managed, so if non-colour managed images are wanted to be handled as sRGB, the value of this setting needs to be 1:

This is how this Firefox setting is described (http://kb.mozillazine.org/Gfx.color_management.mode😞

Quote

Possible values and their effects

0

Disable color management.

1

Enable color management for rendered graphics.

2

Enable color management for tagged graphics only. (Default)

Note: These values apply to Firefox 3.5 and SeaMonkey 2. In previous versions, color management was disabled by default via the boolean preference gfx.color_management.enabled set to "false".

I tried this already yesterday but was obviously fooled by some conflicting setting that made it impossible to apply this setting on macOS, but could now make it work. IMO it is odd that Firefox alone seems to have chosen this policy since probably most of images shown on the Internet are without profile, and widish-gamut displays (like macOS entry-level displays) get more and more common... [As an afterthought: perhaps this is reasonable, not just because of availability of low-cost >sRGB hardware, but because apps typically embed the profile in web images like .png and .jgb, and also because (over)bright displays are so common, so that one could say that aesthetic preferences and expectations have also changed...]

January 17

2 hours ago, thomaso said:

Since the issue disappeared for the OP with a mac reboot it is complex anyway to detect any culprit for the reported issue

Ok, so this, too: should really have translated the whole thread. But at least I myself learned a couple of useful (changed) things on macOS... and strangely, did not manage to get the macOS Firefox work in expected way as regards color management, so uninstalled it already...

January 17

1 hour ago, thomaso said:

Your hint to Firefox colour management options makes me wonder why your settings seem to have "_native_srgb" manually activated

I am not sure, I think the setting was just emboldened because it was selected but I did not consciously change anything. I also later noticed that it seems that it is not even possible to have macOS based (latest) ~~Safari~~ Firefox to simulate legacy colour management modes, e.g. 1 or 0, similarly as it still is on Windows), so my notes are probably out of place on macOS (at least on Sonoma).

When using macOS based screenshots that are saved as PNG files with embedded display profiles, it seems that the only way to get a conflicting colors (especially as regards saturation) when viewing in a browser and taking screenshots, and then opening in Affinity apps, is having the app color setting that forces conversion to default working color space (sRGB) and opening a file with highly vivid colors and a conflicting color profile embedded -- which is not the default setting. On Windows it is a different story.

Profiles

Forums

Posts posted by lacerto

Possible values and their effects

0

1

2

Important Information