lacerto
-
Posts
5,783 -
Joined
Posts posted by lacerto
-
-
On 1/2/2024 at 3:58 PM, Michael Sheaver said:
Holy cow! This Adobe tool is EXACTLY what I was hoping against all hope for! I am dumbfounded and speechless, actually. It not only brings everything into PowerPoint correctly, but it also provides the ability to make final tweaks and edits directly in PowerPoint. Many thanks for sharing this!
If you happen to be on Windows, trying PDF-XChange might be worth your time. It is not quite as good as Adobe Acrobat but not far from it. And it comes with a perpetual license at around USD70.
-
While it is generally true that the color gamut of (s)RGB is wider than that of (typical coated) CMYK, it is good to acknowledge that there are tones within CMYK that cannot be reproduced in sRGB -- in fact, one of the reasons Adobe created Adobe RGB was to get better display predictability for CMYK jobs than when using mere sRGB. This naturally also requires that the monitor supports wide gamut. This clip demonstrates how colors are clipped when converting from Coated Fogra 39 to Adobe RGB (practically not at all) and sRGB (note that on the forum, all colors are truncated to sRGB so the demonstration is not realistic but conceptual, showing that there is a difference):
It is also good to note that when using the CMYK color mode within Affinity apps, the out-of-sRGB colors of the active CMYK color space are not shown because the CMYK mode is limited to sRGB (this can be experienced also when spot colors are used, as their representation in CMYK color mode is limited to sRGB).As for OP's case (practically just tones of magenta), what is mentioned in posts above about these kinds of tones getting truncated when converting to / simulating CMYK target is certainly true, and the additional notes mentioned related to difference of RGB and CMYK color gamuts are basically irrelevant.
-
I think that overrides from underlying styles are by design only shown in context of the Text Styles panel (shown by using a plus sign) -- I do not think that showing a plus sign in controls themselves (like the Paragraph Leading box on context toolbar) would help in avoiding confusion caused by complexity of the feature itself (which IMO behaves logically and as designed [EDIT: though it is an interesting question whether the Paragraph box should show the style-defined paragraph leading which has not been applied, or the actual leading based on original paragraph leading]. The following clip shows what happens when the style definition is applied in a copy of the text passage, clearing the overrides that are left in the upper version and thus applying the style definition, where the original 12pt paragraph leading and font size has been redefined by using a local character-based leading and font size:
To demonstrate what I meant in my earlier post when referring to IDML compatibility, here is how QuarkXPress 2018, which does not support (at least in this version; the later versions that support also IDML export might do) character-based leading overrides, at all. renders (incorrectly) the same IDML imported text shown above in the video, demonstrating that Affinity Publisher renders the text identically with InDesign. The same effect could of course be achieved in QuarkXpress, too, by using workarounds like local baseline shift, etc..
QuarkXPress, on the other hand, supports leading-related features and finesse not available in InDesign and Affinity Publisher. I do not think that any of these apps does leading "correctly" or "incorrectly", they just implement a complex feature differently (e.g., InDesign does not basically support paragraph based leading as a direct attribute and UI control, at all, but just as an option that when applied disables character based leading overrides).
-
The (different) ways leading is implemented in InDesign and QuarkXPress, yet offering basically the same typographic capability, already show that there are no inherently correct ways of implementing line spacing, especially in apps that support "world" (non-Western) scripts. There needs to be flexibility and customizability and the learning curve can be steep.
-
Leading can be confusing, but I think that having it as a setting in both paragraph and
textcharacter context, and both included in paragraph style definition is basically a compatibility based feature, since Affinity Publisher supports IDML, and InDesign supports both paragraph based leading, and character based leading.The way Affinity apps automatically apply a leading override to the whole paragraph, is however a bit confusing and different from InDesign:
InDesign would create a new paragraph style where the override is similarly included as a paragraph style definition, but then the existing line spacing would be retained, and in a way becomes on override to the paragraph style that has a character-override driven regular leading!I do not think that either method is very intuitive, so one must just learn the leading peculiarities in each app.
-
Color management within Affinity apps can be quite tricky and results are dependent on what kinds of images (possibly with embedded profiles), in what kind of a document (RGB or CMYK, which document color profiles are involved), which color profiles have been defined in the app settings (this would be important especially if importing PSD, Photo or other files treated as documents within Affinity apps, or if you have e.g. RGB document and you have an implicit CMYK document profile) and how you export it, and which viewer you are using to examine the results, so an example or more information would be needed.
As a general advise, you are going to get most likely what you expect if your document CMYK color mode matches the target CMYK color space, and you either place TIFF files without an embedded color profile, or TIFF files with an embedded profile that matches your document CMYK color profile, and you then export to PDF by using the document color profile (and do not change the profile at export time). Then, depending on the viewer, you might also need to make sure that the viewer simulates the correct target profile and does not perform recalculations of actual color values saved in the viewed file.
PS. Welcome to the forums!
-
49 minutes ago, David Still said:
embedding and manually deleting the white backgrounds
If you are sure that it is the white background rectangle that causes the invisibility issue (and your printshop cannot accept RGB files), you might want to consider purchasing a low-cost PDF editor (PDF/X-Change, the standard edition of which costs around EUR50, a perpetual license). A proper PDF editor (unlike apps that open a PDF and convert it to native objects for editing, like Affinity apps) can be used e.g. to simply just select and delete objects and save the document otherwise intact. That would make it reasonably fast to remove the background from the PDFs.
-
8 hours ago, David Still said:
Your file seems to work, although I can't say for sure, as the issue happens randomly across many pages. This one page might just happen to work, and others might not. But having to delete the white background of each page of over 140 songs might not be that practical!
If you had experienced the invisibility issue (especially one that results in invisible exported PDF, as well) only or principally after having applied an adjustments trying to block CMY in an RGB based document, then having an RGB full page size white background rectangle (basically without a reason) might be a likely trigger for this error. But I understood that you have experienced this, similarly as I did, also without applying any adjustments, as long as there is an interpret mode PDF placement involved. But then this would appear to be more a rendering issue and something that I would expect would not happen in an exported PDF. This might somehow be also a system specific issue (even if you mentioned that disabling hardware acceleration in the app performance settings has not had any effect on the problem).
-
6 hours ago, thomaso said:
Do you have an idea what exactly triggers the right shift/offset of the drop caps when overlapping in the bottom example?
I probably did not understand fully what you mean and leading constructions are quite tricky (much because they are so powerful). When I tested this, I think I could make it behave consistently, excepting the Drop Caps based based formatting where small leading causes an anomaly, a kind of a two-line drop cap, while when using Initial Word based initial, this does not happen.
6 hours ago, thomaso said:Is this the expected behaviour for an assigned Drop Caps style? ... and the same in V2?
My brain hearts already, but I'll try: if you meant that manual changes to initial character do not have effect in case the initial is formatted based on a character style saved as part of a paragraph style then I think it is "by design", and meant to be protective (the applied character style is in a way implicit, it does not show similarly as a manually applied character style, which could be manually edited; I think it is similarly in InDesign).
BTW: The initial formats and styles for the version 1, attached above, were created by copy pasting from version 2 (apparently the only way to do it), and it was awkward: in practice nearly everything had to be redefined in version 1.
-
3 hours ago, thomaso said:
This will scale the initial character accordingly, regardless of the font size of the paragraph style … and without the need for additional special characters.
This is great, I had not realized that scaling with 1 line is free of the line spacing multiplication limitation (contrary to multiple line drop caps where scaling is automatic), so the scaling can basically be anything and even overlap any text above without adding space, so exact line spacing and space above alone determine the space above (similarly as when doing this with the initial word trick). "Auto" mode of drop caps is also smart enough to allow preceding properly formatted drop caps, like quotation marks, and ignored markers like zero-width space that allow automated formatting. Drop caps have also some additional formatting control so it is really the preferred method to do this!
-
14 minutes ago, David Still said:
If I pick passthrough, can I not export in grayscale as you explained above?
No, Affinity "passthrough" means that the color mode is retained (contrary to many other similar apps that pass through PDF files). This is demonstrated on the video and can be easily tested. Only interpreted (and opened) PDFs can have their properties changed.
The invisibility issue is odd, and I cannot reproduce it consistently, but if you can, and as it is also an issue in the exported PDF, i do not think that you have other options than using passthrough. As mentioned, it is basically the foremost choice to work with PDFs though there are exceptions. I would really ask the printshop if RGB output is fine -- as mentioned, it is very easy for them to convert RGB to grayscale, but some printers have so automated workflows that they do not accept this, so it is best to make sure.
If you pass through, I do not see the point of editing the files (especially if you do not experience the invisibility issues when passing through).
-
I might have misunderstood something of the goal, but one solution could perhaps be applying an initial word (max 1) paragraph formatting with all letters of the alphabet (and figures 0 to 9) defined as formatting stoppers, and a character style to define the initial itself. This would allow automated formatting, as demonstrated below:
-
10 hours ago, tzvi20 said:
I have seen a bunch of requests for DOCX export so hopefully we will get it soon. It will be very helpful for me so patiently waiting for it.
It is definitely a useful feature (and sometimes an essential one) in a professional page layout app and especially in complex multi-editor workflows, even if only supported at RTF level. In certain situations it can even be used as an exchange tool e.g. to give an RTF file for revisions and then import it back, keeping practically most if not all formatting changes already made in the layout, or even just to indicate changes made in the layout between two time points (often much more useful than a PDF comparison, which on the other hand can show the exact locations of changes in the layout).
-
I do not think that you can do it, unless they are all on the same page. Only in that situation will the Locate in Document button be available in the Resources panel so that if you arrange the objects by status and then selected them and click Locate in Document, the page containing the missing objects will be brought in focus and the located missing objects objects are selected (and show selected in the Layers panel).
If the missing objects are on multiple page, you can use the Resources panel to locate a missing object one at a time (e.g. by arranging the object by their status and then double clicking a missing object) and then click the Delete button of the Layers panel (where the located object is selected). But it seems that there is no way to select objects by status on multiple pages and then delete them all with one action.
-
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.
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).
-
16 minutes ago, David Still said:
Thank you for taking the time to test my file! But when I open it in Publisher the eyedropper tool gives the CMYK values 72, 68, 67, 88, exactly where they started.
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):
-
46 minutes ago, David Still said:
I also tried exporting a spread that didn't have the adjustment, using Gray/8 like you said, but it was still four color black when I opened the exported PDF in Publisher.
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!
-
42 minutes ago, David Still said:
I only do this only because it's a fraction of a second quicker than dragging a copy from one spread to the next.
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.
-
21 minutes ago, David Still said:
Musescore also outputs RGB, so what I've done is add a selective color adjustment over the placed PDFs, subtracting CMY, and adding K.
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.
-
On 1/21/2024 at 11:05 PM, kenmcd said:
Music PDFs can only be placed as passthrough.
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.
On 1/20/2024 at 11:11 AM, David Still said:There is always a large amount of pages missing this way, and it seems to be random
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.
-
14 hours ago, soggybag said:
I tried making a copy of the document and including the cover but this seems inefficient since any updates now have to be applied to both documents.
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:
-
3 hours ago, ms.fuentecilla said:
Lacerto, the file is not a pdf, it is Publisher which is exported as pdf for the printer
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):
-
12 hours ago, Oufti said:
It's definitely commonly advised to use LibreOffice to open and resave as .docx a corrupted Word file, as this software interprets quite well all Word features and re-encode them at export.
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
Book on affinity publisher pdf not accepted by book publisher
in Affinity on Desktop Questions (macOS and Windows)
Posted
If consulting the referred PDF creation guide, e.g. at
https://assets.lulu.com/media/guides/en/lulu-book-creation-guide.pdf
it appears that sRGB color mode is recommended, and as for CMYK, the recommended CMYK color profile is Coated GRACoL 2006 -- but the recommended maximum ink coverage is max 270%, which is something to look out since this CMYK profile allows max 330% coverage so excess ink is not automatically decreased when exporting. This is why it would be ideal to be able to produce a pure RGB based PDF export since color production would then be performed by Lulu.
The only way to automatically produce flattened PDF with Affinity Publisher (in addition to rasterization which you want to avoid) is to export using PDF/X-1a or PDF/X-3. But whether to try either, much depends on what your document contains (just text and photos, or e.g. placed PDF files), in which color mode (RGB or CMYK/8) it is at the moment, since using either with these export methods is going to convert native elements (text and shapes) to CMYK [the former will also convert images to CMYK]. And to avoid problems with excess ink when converting RGB objects to CMYK is to make sure that text and native shapes have already been defined in CMYK color mode and use max 270% ink for colored objects and 100% K (CMY 0) for black text.
Another option to flatten transparencies is doing it manually in the layout. If the transparencies only consist of e.g. PNG bitmaps with transparent background and your document is in RGB color mode, you can rasterize them on the canvas, and then continue producing your PDF in the way you have done so far, because Lulu appeared to accept the export (except of the transparency). If there are other kinds of transparencies (layers with <100% opacity, etc.) it can be trickier, but still successful, especially if your document color mode is RGB.
EDIT: I later tried to produce a manually transparency flattened RGB PDF with poor results (trying in vain to flatten e.g. PNG files with transparent background), so it really seems that creating a PDF/X-3 based PDF (with possible photos in RGB color space) is your best choice. In this case it is a good idea to make sure that all black text is defined as C0 M0 Y0 K100, and that all shapes have CMYK color definitions, total ink coverage of which is below 270%.