lacerto

The text actually does convert to curves (and is not rasterized) when the transparency gradient is applied directly on text and not a separate object. feathering_simulation.afphoto feathering_simulation_on_vectores_improved.pdf

Yes, in that respect the simulated feathering works fine: shapes and strokes they are applied on stay as vectors and editable, as does text.

Yes, you're (partially) right. In the vector version the feathered shapes do not cause rasterization of the underlying ellipse (similarly as flattening of transparencies do), and both objects can be moved freely on other parts of the image while keeping their transparency effect. But the text is rasterized (I wrongly assumed that it was only converted to curves). But it is better than I initially assumed.

Sorry, my judgement was premature. Earlier when I tried this with Gradient tool, shapes and text, my PDF exports were rasterized, but not when I just tested this again (it is only if transparencies are flattened using PDF/X-1a or PDF/X-3). feathering_simulation.afphoto feathering_simulation_on_bitmap.pdf feathering_simulation_on_vectors.pdf

Selecting all and exporting to PDF then opening (in Designer 2), lets add the objects to a curves object in one go. Perhaps PDF export somehow reorganizes the job and does away the reason why the Boolean add initially fails.

Yes, it is insane that you can basically apply e.g. all feathering and other transparency related effects (including blend modes) and flatten them to PDF/X-1a [or just plain flattened with PDF 1.3 in either CMYK or RGB color mode] without causing rasterization.

No, it is not possible in the sense that is possible e.g. in InDesign where you can apply feathering on shapes, strokes and text and retain editability, without causing rasterization. feathered.pdf

I think the trigger is if leading gets so small that the "drop cap" of the next paragraph hits the baseline of the preceding line, so it depends also on the character that acts as a "drop cap". UPDATE: If it is a continuing line (instead of multiple drop caps on one-line paragraphs), the trigger is if any of the character shapes on the next line hits the bounding box of the "drop cap", then the wrap occurs [in my demo above it is the character "h" that hits the baseline of the drop cap]. This does not happen when using the Initial Word trick. UPDATE2: The actual baseline can be shifted up or down so it seems to be the zero baseline that counts!

It appears as if a placed PDF will always be rasterized/shown at max 300dpi no matter in what kind of a Photo (e.g. 1200dpi) it is placed on. You get a better, less blurred rendering by opening the PDF and then scaling to desired size, and rasterizing only after that (this is different than in PS where a placed image will be rasterized at full resolution but you cannot e.g. choose whether to use antialiasing or not similarly as you can when you open a PDF in PS). a) Rasterized from directly placed PDF on a 2400dpi image: b) Rasterized from a an opened and scaled PDF on the same image: UPDATE: If you have all resources of the placed PDF available, then you can choose to "Interpret" the placed PDF instead of using "passthrough" and the rasterized preview of the file content, in which case you will have fully rendered PDF content displayed. If you rasterize the image at this stage, it will be rendered at document DPI. Photoshop will do this purely from file contents so even if you do not have a font embedded in the placed PDF installed on the system, the rasterized text will be rendered at full resolution using the embedded content. Affinity apps cannot do this, so embedded but not installed fonts would be replaced with another font installed on the system, but vectors would be rendered at full resolution, so if your landscape plans are vectors, showing the PDFs as interpreted would render them sharp when you rasterize the placed and interpreted PDFs on your canvas. PDFs placed for "passthrough" will only have their already rasterized preview image resampled on a pixel layer at document DPI, and as for fonts, installed versions would not be used for optimal rendering even if they were installed.

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%.

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): adobergb_srgb_coatedfogra39.mp4 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: override_indicator.mp4 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 text character 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: overrides.mp4 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!

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.

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).

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. 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). Initialsv1.afpub Initialsv2.afpub 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.

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!

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: raised_initial.mp4

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. 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).