lacerto

I fetched the fonts you had in the demo document so that I can demonstrate properly the method of producing purely DeviceGray print PDF keeping all in vectors and text as text [or basically all as "text" since notation is done using fonts]. The clip below also demonstrates what happens if you choose to place RGB based PDF for passthrough: you either get RGB output, or if you force to CMYK, rasterized four-color output. You can try to apply Channel or Colorize adjustments and force output to K100, but you cannot avoid rasterization. scoreoptions.mp4 As mentioned above, you can of course convert everything to outlines (before or after) if you do not mind losing text (and probably creating bigger file sizes). But if you pass through, you will have the same color issues as mentioned above. As it seems that Publisher renders very well also the fonts used in MuseScore notation, I would try if interpreting (without using any adjustments) works. If you continue getting "invisible PDF" issues, then passing through and producing RGB would be the best option, and then making sure RGB output is not a problem to the printshop. [It is practically a question of pushing e.g. Adobe Acrobat Pro button to convert RGB PDF to grayscale so any printshop should be able to do it.]. Invisible song-Musescore output-01_gray.pdf UPDATE: I forgot to mention that I have hw acceleration on, and while I have experienced the disappearance issue two times when using interpreted mode [the second time only for one page when using a CMY blocking adjustment], this has not happened consistently, and it has not prevented creating fully working print pdfs (from a relatively small, 20 page publication).

No, that happens if you open it in CMYK color mode, or if you have the sliders locked and read color values in CMYK mode. If you let Publisher estimate the color mode, if will open it in Gray/8 color mode. If you then set the sliders of the Color panel to Grayscale mode, you can see that all elements including text are Gray 0. This can easily be shown in Adobe Acrobat Pro: Note too, that as I mentioned, passthrough will keep the job as vectors (non-rasterized), but it will also keep the job RGB (or if you force to CMYK, it converts the RGB black to four-color black). Some printers do not have problems accepting RGB jobs, so I would ask if it is ok, since otherwise it is normally safer to place PDFs for pass through. If you do not have prepress tools to convert RGB black to K100, and the printer requires K-only, then your choice is to either open or interpret the original score and export explicitly to gray, as I have demonstrated. As I do not have your notation fonts installed, I cannot check how well Publisher interprets the score but it does it basically 100% correct when using Sibelius scores. The correct export settings are as follows (just remember to have your document color mode RGB):

Please make sure that you have the document color mode as RGB and export color mode as Gray/8, ICC profile as "Use Document Profile", do not check "Embed ICC Profile", and make sure that you force conversion of image color spaces. This way you should get the following: Invisible song-Musescore output-01_apubgray.pdf Note: The PDF above has obviously notation errors since I do not have the fonts installed. BTW: I applied channel adjustment to block CMY and managed to output an empty PDF page, so this might well explain your dilemma!

I see. I normally just copy paste one spread (two placed pages) at a time. Ctrl+C (Cmd+C) on one spread and Ctl+V (Cmd+V) on the next, since Affinity apps paste in place by default. There might be point changing Passthrough to Interpret after the first placement as Affinity remembers the setting for the rest of the placement in that document. At least it should reduce one manual one-by-one step from the workflow.

Can you post a sample of the output? If I try this, my output is rasterized and four-color black, but it may be dependent on combination of document color mode, settings and adjustment that might work. Anyway, I have the document color mode as RGB and simply just export using Gray/8 with document profile (=D50, basically Gamma 2.2), not embedding profile, and the whole file will be DeviceGray (= K100). Your adjustment, btw, might be cause to the disappearance or glitchyness of the PDF display! Your example showed that there really is no object so if it is invisible, nothing seems to be output. Did you apply the adjustment on the sample score? The notation was in four-color black while separate text parts were in black (K100).

The "transparency" in your image is faked, and actually just checkered pattern with white and light gray color values with 100% opacity.

That depends on the app that produces the PDF. I have still the old version of Avid Sibelius (version 7.1.3) which exports PDF that renders practically perfectly when interpreted or opened in Affinity apps. As Sibelius produces RGB output, interpreting or opening is practically the only choice if the print PDF needs to be in K-only (unless a tool that converts the output to K-only is available) since Affinity apps will either keep RGB when passed through, or if forced to CMYK, will produce four-color gray. As for passthrough, Sibelius produced PDFs are v 1.4 and they pass through just fine, without rasterization, but as said, the output is RGB. I have tested many score creation apps in Publisher during the recent years and it is true that PDFs created by some apps do not work at all even if all fonts are present (I guess it depends on encoding). Sibelius comes with 17 Opus notation PostScript flavor OTF fonts (by Avid) and at least the scores I have tested them with (only a few) they appear to behave very well in Affinity apps, both rendered and in the Glyphs panel. As for disappearance of placed PDFs (for interpretation), I did experience something similar, but that appeared to be after first placing all pages to be passed through and only after that switching to interpret mode one by one, and all pages except the last one disappeared both on canvas and in the Layers panel. But I saved the document and then opened it, and then all pages showed. Rendering however was a bit sluggish and I can imagine that having over two hundred pages to be interpreted can be a challenge. But it would seem that this is a different issue from yours as you experienced missing pages also when using passthrough mode (which I have not; but I would imagine that switching from interpret mode to passthrough when page is invisible would not necessarily make it visible).Anyway, when later switching immediately to Interpret mode (Publisher remembering the last used setting and keeping the mode), I did not experience disappearance of pages. But I only tested this with a score consisting of 19 pages. I did not try to export to PDF at the time the pages were invisible, but I am surprised to learn that the pages were not visible in the exported PDF, either. Can you post any of such PDF on the forum to be able to have a look on the file (whether the actual content is there but for some odd reason just invisible)? UPDATE: In my case, I was placing different pages of the same PDF document, copying already placed pages and then defining the page to be displayed from within the context toolbar. It is probably different from your situation where (if I understood correctly) most placed pages come normally from different (linked) PDFs. My files in context of Affinity apps are always on an internal SSD.

The print cover often needs to be prepared separately for multiple reasons: the color profile might be different because of media difference (e.g., coated cover, uncoated inner pages, colors in cover only, size difference if there are things like flaps, need to have front and back cover + spine in one continuous print area, etc.) To avoid need to do updates twice, place the print version in the digital version and position and crop it properly for front and back. When linked, the placed PDF will update whenever you have modified the print version. When you prepare the print version, just export the inner pages. Typically you would start numbering from the title page so when you insert pages for the cover, you would typically number than e.g. with Roman numbers (I, II for the front cover and III and IV for the back cover). Note that when you have a facing pages layout and you want a compatible PDF viewer to show the pages as spreads, the viewer must additionally support showing the first page as a cover page. These so called "initial view settings" can be saved as viewer instructions (only recommendations which can be ignored) within a PDF but so far you cannot do this by using Affinity apps, but need a separate app where this can be done, e.g. Adobe Acrobat Pro, or similar:

Ok, I misunderstood. If you have the number field inserted on a master page, ensure that the master page is applied to regular pages, and also that you do not have something that covers the page number (if you do, move the master page layer on top of other layers so that the page number shows): pagenumbers.mp4

Yes, it seems so. However, in the end using Word to "fix" the tracking issue was adequate, as the issue that caused Word becoming unresponsive could be avoided simply by rejecting (instead of accepting) the last made changes that the author had made to hide part of the content, and especially by rejecting one fatal formatting change which probably caused the crash because if accepted, alpha-formatted list was applied to rest of the text paragraphs (including inside tables), creating absurdly long alpha indexes. After doing this, tracking could be stopped and the document behaved just fine. So this "error" was a kind of a secondary issue not related to author's actual dilemma with Publisher importing numbered lists incorrectly. The numbering issue itself was something that could (a bit surprisingly perhaps) be improved when taking the document to LibreOffice Writer and simply just letting it save the document. On the other hand, Pages could import numbering correctly even without this fix so it is unclear whether there were initially any errors. But after the file was saved using LibreOffice Writer, InDesign could import the document so that numbering was retained and related styles correctly defined (with only two exceptions at the start of the document). Publisher however still imported incorrectly the lists encoded by LibreOffice Writer. As a general note, Publisher still appears to lack tools that make it easier to fix numbering errors, most importantly ability to flatten autonumbering to text, and it seems, also ability to apply "continue numbering" command (as a pair of restarting numbering, which is supported). When document hierarchy is several levels deep, and numbering schemes are complex, it is often easiest to go through auto-numbered lists one by one in sequence and first make numbering corrections using automation if possible, but thereafter flatten the list (which is often also useful for checking formatting integrity, since indexes of auto-numbered lists cannot be selected. Sometimes a lot of time can be saved by simply just flattening lists and typing in correct custom indexes that do not come naturally and cause problems. Converting autonumbering to text is also supported in Word, but I think the feature can only be accessed via a VBA macro (which could of course be placed on any of the toolbars or menus). In case someone is interested, here are the required macro commands (operable both in Windows and macOS version of Word): Sub ConvertListsToText() ActiveDocument.ConvertNumbersToText End Sub Sub ConvertActiveListToText() Selection.Range.ListFormat.ConvertNumbersToText End Sub

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!

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.

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. scrollingbug.mp4 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.

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:

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

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.

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]:

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.

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.

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.

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

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. 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. 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): outerstroke_ai.pdf outerstroke_ai.svg outerstroke_ad.pdf outerstroke_ad.svg 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. 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.

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

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.

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.