Jump to content

Lagarto

Members
  • Content count

    745
  • Joined

  • Last visited

Everything posted by Lagarto

  1. Based on the print file that was created (just about 36kB), compared with the about 1,600kB created when printing imported graphics (which gets pre-rasterized). Also, increasing the dpi setting when printing opened graphics (which is not pre-rasterized), does not increase the print file size. Also, when printing opened graphics and setting the resolution at e.g. 50dpi, the print quality is still the same. The difference in sharpness between the standard 300 dpi vector/font-based printout, compared to 1200dpi prerasterized output, may be explained by driver optimizations and may be printer-specific. I do not know enough about print technology to be able to say whether there happens any smoothing out (aka. antialiasing) or optimization when printing vector graphics and fonts (as opposing rasterizing without such devices but using a higher accuracy) onto a modern laser printer (similarly as happens when rasterizing on a computer screen or on a low-resolution printer), but e.g. fonts (possibly also notation-related fonts) have hints that have some effect on printouts which can result in visually beautiful rendering, even if the data sent to the printer, when looked close enough, has more smudge and less detail.
  2. You mention that you experience low-resolution print quality issue also when you use SVG files printed from Publisher. Please try if opening the SVG file instead of importing (placing) makes any difference, or if you import (place) SVG files, setting the resolution at e.g. 1200 dpi (or maximum of you printer resolution) at print time, and ensuring from the Properties (from within Publisher Print dialog box) that you do not have any print optimizations checked that have effect on quality of output. You also mentioned that you experience print problems when trying to print scores imported to Publisher either as PDF or SVG files. Do you mean that this happens also when you export a PDF file (e.g. X-4 mode or "(print)") mode and try to print it? In that case, which application do you use to print your pdf files (e.g., Adobe Acrobat, your browser, etc.). The PDF you provided was created from your notation software and it printed just fine, and when I have exported pdfs from either opened or imported PDF or SVG score you have provided, I have not been able to reproduce the problem. It is possible that you have some printer driver issue, but it is strange if similar problems cannot be experienced when printing from other apps to the same printer. Printer settings however can be app-wide selections, depending on the printer and how it is connected to your system (e.g. on a local port or on network), so it is possible that you have a setting in the driver that forces e.g. 300 dpi or "fast" rasterization, and that affects only printing from Publisher.
  3. Here are printouts made from Publisher onto a Dell 3130cn laser printer (internal resolution 1200dpi). There is no practical difference in print quality whether the job is printed from an opened SVG (sent to the printer as vector data and rasterized by the printer at its maximum internal dpi, disregarding the default 300dpi setting of Publisher), or from an imported SVG (sent to the printer as a rasterized sheet resolution set at 1200dpi). As can be seen the latter has more details but when viewed from typical read distance, both look practically identical. Attached is a zip file containing also printouts made from imported graphics using 300 dpi draft (tone-saving) and 300 dpi high-quality settings. Even if some differences can be discerned and the quality is poorer, there is barely any difference when viewed at read distance. But when printed on a lower-resolution laser printer, or on a regular office inkjet printer, there can be more significant differences. Note that these images have been photographed with a mobile phone without a stand, converted to gray scale and normalized, so the output is clearly processed, but the images are nevertheless helpful when trying to compare the quality of different open/import and print methods. notation.zip
  4. It seems to send all imported graphics as rasterized information to the printer. Imported SVGs are in vector format so I guess they behave exacty same as PDF or EPS containing vector objects (and fonts). EPS files do not seem to support fonts, either, so as for scores, where you render most of the stuff with fonts, I'd use PDF or SVG format. And I would open rather than import SVG (similarly as PDF), to be able to send the printer data without pre-rasterization. I do not say that you get necessarily better results (as the printer can only rasterize at its maximum dpi), so sending pre-rasterized data at high enough dpi value is likely to give you same results, but at least you avoid driver related problems like print optimizations, that are likely to happen when printing large bitmaps (like whole sheets of scores that have been rasterized), and will most probably also get your sheets printed faster. And thanks for the hint on SVG avoiding positioning problems. They can be opened and imported perfectly aligned, contrary to PDF files. This was valuable information! Here's an actual screencapture of a print file produced from opened SVG file (in Publisher), and printed with default resolution (300 dpi) using the Dell 3130cn printer driver, resulting in a 40kB print file that is not pre-rasterized (so the dpi setting is irrelevant): But this is of course irrelevant, as what is shown above is just a result of rendering the output on the screen of my computer. This would get printed at maximum dpi value when actually processed by the printer. I can run a test and check the output when I get to the office later today. Here is output when the same SVG file is imported (placed) in Publisher and then printed at 2400 dpi using the same printer driver. The resulting file size is 1374kB so the whole sheet has been prerasterized: This is seemingly more jagged, but when zoomed in shows enough detail to get printed crisply and without any pixelation on the printer:
  5. Your score file would actually be a good test case for Serif to get some major problems with object positioning when importing / placing vector graphics (eps/pdf) fixed. I opened you score now in Illustrator and QuarkXPress and there were no problems with object alignment. Affinity apps open pretty well other kinds of complex jobs, but not these kinds of at least seemingly relatively simple jobs! If you do not experience these kinds of problems yourself, it may be somehow system dependent, but it does not appear to be system dependent because I can open the pdf in Illlustrator or QuarkXPress without any problems at all with object alignment.
  6. One further note: as Publisher does not support pass through at the moment, you are likely to get rendering errors no matter whether you open or import your scores. E.g., the stems are not aligned correctly when I open or import your pdf (as can be seen from the printouts above), yet they show perfectly aligned in the pdf. This might be not a problem if you create and subsequently open/import the files on the same system, but as long as pass through is not supported, I'd not import any vector format file in Publisher (or Designer) without carefully checking that objects are correctly processed.
  7. Note too that when you print pre-rasterized images, the print quality may be determined by your print driver (e.g., optimizing the speed), while when you print vector objects and fonts, the full dpi of the printer is typically used. So the reason you get visually rasterized output when printing rasterized stuff from Publisher (even at high dpi values) is probably explained by the default print setting you are using. The output shown above at 1200 dpi should be sharp enough on a typical laser printer (and even on typesetter, though there the rendering is often done at 2400dpi or even higher).
  8. Printing means ultimately always rasterizing, so the quality you get should depend solely on the dpi setting you use when you send the job on the printer (and obviously the printer capabilities and possible driver settings having effect on print quality). I opened your pdf in Publisher now in two ways: by opening the pdf (so that everything is in vector format and rendered with fonts), and by importing it as a pdf. When I produce a print file from the opened file, the print file is not pre-rasterized so no matter what dpi value I use for the printing, the print file size always stays the same (about 37kB), and rasterizing is left for the printer. But when printed from the imported graphics, the dpi value determines the quality of the print, below examples of using the values of 50 dpi and 1200 dpi. Print dpi at 50: Print dpi at 1200: The reason Publisher sends a print job containing imported graphics as rasterized to the printer is probably related to its inability to simply pass through documents, or possibly because it works differently as it is an app that can combine documents from multiple sources and needs to perform calculations on total effect of layered elements to guarantee proper rendering in different kinds of scenarios. Anyway, you should be able to avoid the problems with the print quality when using Publisher either by opening your scores as pdf files (rather than importing/placing them), or using high dpi value when printing.
  9. If you have a transparent colored area on top of a white object, it looks different than than on a transparent object, unless the "paper" (background) of a document is calculated as white. When you create a PDF file, the document background is by default shown as white, unless specifically ignored (considered as transparent), so you get results that you want in most situations. If you use the option to flatten the pdf, Publisher will rasterize the document, but when it does, it does not flatten the objects with "white" background (but leaves the background transparent, if it is transparent in the original images), which results in colored transparency looking different on white than on transparent background (unless the viewer software adds the background). Whether the background of the resulting pdf is shown as uniformly white depends on the pdf viewer and the way it renders the image. To avoid the problem, you should export the pdf using some other option than (flatten). You could also add a white rectangle behind all objects to guarantee that you have uniform white background behind all objects. That would let you avoid dependency on viewers and ensure that the background looks the same whether you have transparent or white background in your source images.
  10. In addition, while having object(s) selected, zoom-in shortcuts like Ctrl +1, Ctrl+2 etc should ideally center the selection midpoint (or text cursor, if active) in the view, similarly as in InDesign (and to some extent QXP). This is an important usability feature and should be easy to implement; if there is any reason for not making it the standard behavior, it could be added as an option in the Preferences.
  11. Lagarto

    Halo in gradients?

    Please choose the Fill tool and click the object where you have the gradient, to display the gradient vector. You had set the gradient for a quite narrow area (default being from edge to edge) so the change between the basic color and its low-end tint value was abrupt. By using short vectors and in-between color points, you can create halo effects (e.g. to imitate metallic shine) in purpose.
  12. Perhaps a macOS thing? Copy pasting from APub to Word (latest version) on WIndows 10 pastes all Scandinavian and even more exotic characters (tested all up to and includin Latin Extended A) ok.
  13. Yes, Publisher uses component values of the color model (HLS; RGB, CMYK etc), and libarary names (e.g., from Pantone) if you create a swatch as a local color (you can then subsequently convert the swatch global from the context menu). PMS color names also appear if you list the library colors with color names (Appearance > Show as list on the Swatches panel menu). The Pantone Blue does not appear in the PDF because Publisher has converted the gradient between the two PMS colors (Rhodamine and Pantone Blue) to CMYK. But it has been defined in the Publisher file as the other end of the gradient color.
  14. A good question, as it basically just adds another gray scale ramp and is technically much the same task as supporting more than one spot color in a document. But it may have something to do with the fact that that spot color definitions are not expicitly listed, anyway, nor are gradient definitions (e.g., so that end colors specified with swatches would show this status after the colors have been assigned), so they tend to get converted to document color space in more complex scenarios.
  15. Working with color is more or less awkward in current state of Affinity apps. As for adding colors as swatches, my preferred method is to create a dummy objects (e.g. rectangles) and then assign them one by one color values (either from the libraries, or by using sliders and desired color mode) and when done, activate the document palette, and select the colored dummy objects one by one, and clicking the "Add fill to palette" plus button to get the actual color value or library color name added as a swatch, and then right click the swatch and convert it to a global swatch. As for tints, ones added as swatches lose their parentship to the base color, so if you change the base color, the tints do not change accordingly, so if you need that feature you just need to assign the base color and specify tint values as ad hoc percentages. Also, as swatch names cannot be updated (automatically nor by command) based on edited color definitions, you need to do that manually.
  16. Can you include a sample pdf that gets corrupted when imported and subsequently exported from Publisher? It seems strange that objects that are truly in vector format get poorly rasterized when printing (they get rasterized naturally, in the end, but the quality should be purely a print-time setting if the source material is in vector format). Also, when printed directly from Publisher, the print quality should be determined solely from the dpi setting specified on the Rasterization section of print dialog box. It is a general issue with Affinity apps that they cannot use embedded (non-installed) fonts (in PDF or EPS), nor convert them to outlines, so you'll be guaranteed to experience all kinds of problems when importing notation documents, which typically have many elements rendered in type. But these kinds of problems should simply show as missing or mistakenly replaced elements rather than as problems with rasterization at print time. Even if passthrough is not supported (but instead Publisher silently re-processes and re-renders an imported, or "placed", as the term appears in the menus, pdf/eps file when producing the print pdf, e.g., replacing missing fonts (so "linking" or "emdedding" are both terms that are actually inaccurate in the context of Affinity apps), my experience has been that only unsupported features get rasterized unless explicitly specified in export settings, so print-quality-wise there should be no problems. I tested this with a one-page sheet using heavily fonts for rendering the notation, with 134KB size. When imported or opened in Publisher, most of the stuff is just lost (or mistakenly replaced, if you allow font mapping). When opened and converted to outlines in Illustrator or CorelDRAW, and saved as PDF (no fonts included), the size grows to 400 up to 778KB (depending on options used). The resulting pdf seems to open correctly in Affinity Publisher, but when exported to PDF (X-4), the size is grown to 1,635KB, but still looks fine and everything has stayed as vector objects. When printed on laser printer (max 1200 dpi), there are no problems with the quality.
  17. A further note on this: PMS gradients between two different spot colors are converted to CMYK not only when importing a PDF but also when produced from a native .apub file where the end colors are specified with PMS values. See the attached files. So rather than a bug, this seems to be a feature not (yet) supported (???) pms_gradient_apub.afpub pms_gradients_fromapub.pdf
  18. This seems to be more a problem related to listing the opened/imported spot colors in Publisher than lack of support of spot colors when opening or importing a pdf with spot colors (and subsequently producing a print pdf). This happens whether you have a spot color in a solid object, or as a component in a gradient (the other end of which having a tint value of 0 of the specified spot color). Please try this with the attached pdf with a gradient and solid object using PMS Process Blue (produced with InDesign). When you open (or import) the pdf in Publisher and the produce a print PDF, the spot color is correctly maintained. You just cannot see that the spot color status is maintained, unless you create a document palette and then create a swatch based on the imported color. When you do, you can see that the swatch has the spot color mark in the bottom right corner of the swatch. See the attached APub file. pms_gradient_plus_solid.pdf pms_gradient_plus_solid_fromapub.pdf pms_gradient_plus_solid.afpub EDIT: Sorry, failed to understand that you meant a gradient between two different spot colors (rather than a ramp of one spot color just fading out). Yes, gradients between two spot color values are indeed converted to CMYK.
  19. The feature seems to have improved since the time the topic was created as moving by scrolling seems to happen reasonably smoothly even in a large document (by accelerating the scrolling by dragging outside of the top/bottom of the Pages panel), and especially when using small page preview. As acceleration is relative to the distance the off-panel dragging happens, it may be useful to make room around Publisher window to allow more distance and the maximum speed. I have not tested this with complex page content, though (just with about 400 pages with text and two large images placed on the master pages). There might be point in allowing page items without any preview (thumbnail) at all, in situations where highly complex pages might slow down scrolling (though it does not seem that page content makes scrolling any less effective). Allowing moving a page selection to specific location ("Before page n", "After page n", "Beginning of document/section <n>", "End of document/section <n>") would be convenient, too, but I can see that this may be tricky feature to implement, e.g., to avoid illogical operations (e.g., trying to move selected page range within itself).
  20. I had a second look on this and created a similar effect from the scratch, but could not first reproduce the error. All effects where rich black was applied printed correctly on all plates (rather than printing only on K plate and as if knocking out other components), no matter which PDF mode is applied (X-3 or X-4). The problem with the test job you provided was that even if the black of the effect consisted of all four color components, the effect was actually applied in K only (also in X-3 mode). In X-4 mode the rich black also appeared to knock out underlying color of other objects. I noticed that the photo you had in your file was in CMYK format. The test photo I used was in RGB format (while the document color space is in CMYK format). The blending effects are typically calculated in RGB color space no matter what is the document color space, so I converted the photo in CMYK format and imported it, and applied the same effect on it, and that's it, the problem now appears on the CMYK copy of the photo. So it seems that Publisher fails to apply effects correctly to CMYK photos, even if the document color space is in CMYK format. Please see the attached files. test_fx2.pdf test_fx.afpub
  21. I opened the file provided and it seems this is not a problem related to overprinting but rather an issue of not applying CMY components of an effect (only K component of the effect's color is applied); the result is basically similar as when the black component knocks out other component colors rather than overprints, but in fact the black of all effects applied in this job consists of all four color components, and the CMY components simply just fail to print in X-4 mode (but not in X-3 mode). I am not sure if this is a bug related to X-4 pdf mode, or a result of applying limits of the specification (but failing to rasterize the effects) but it seems the problem can be avoided if you you select as the "Rasterize" option "Everything" rather than the default "Unsupported properties".
  22. I tested this in InDesign, and there overprinting seems to happen much in a similar way when applied in context of effects where the white (screen) has effect on the overprinting black area, e.g., in context of inner glow and bevel. But in InDesign, Outer glow effect (where white is spread outside of the object), does not knock out the underlying color of the black object that has the effect applied to, so black gets overprinted in this situation (as it does when applying outer shadow, similarly as in Affinity Publisher). I still could not reproduce the difference when using X-3 or X-4, but perhaps the way effects extending to the outside of the object (especially outer glow) operate could be changed so that they still allow overprinting of black, similarly as now with the outer shadow?
  23. A further comment on the way white should work in effects: e.g., in bevel, or inner glow. Now it affects the total area of the object to which it is applied, whether this object is set to overprint or not. It could be tried to be applied also in more limited way so that the overprinting still occurs where the effect of glow or bevel does not have effect. But my point above was that I could not reproduce the difference in overprinting behaviour when using X-3 and X-4 export options. The way white (or other non-K color) operates in effects is a complex issue when applied in context where K is supposed to overprint, and IMO "gray area", where I do not expect clear-cut results.
  24. There is an overprint difference in the pdf output or the attached two files, but can you provide the apub file so that the values of the applied effects can be checked? I tried to play with effects but could not reproduce the error with just "Outer shadow" effect (where mere K value is applied). But when combined with other effects, e.g. bevel effect, the constituting white part (highlight) will knock out underlying color (as it should), but then it does this both with X3 and X4 modes. But using mere K value (which is set to overprint) in the outer shadow seems to work correctly (overprinting) no matter whether exported to X3 or X4. It does this both when using K100 and using the export option for overprinting black, or using lower K value, like K75, which is set to overprint as a swatch setting.
  25. Here's one real-life scenario I can imagine (I would prefer an opportunity to be able to convert any selection of text directly to outlines, and in place, replacing the original text content, similarly as in InDesign, but unfortunately this is not possible in Publisher; the minimum unit is a text frame, and then the original text content is not replaced but simply pushed away, which can be seen when there is a link between the frames): The obvious reason for converting the middle part is converting text to graphics to disable text-based collection of email addresses. split_text_curves_text_scenario.afpub
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.