Jump to content

Lagarto

Members
  • Content count

    610
  • Joined

  • Last visited

Posts posted by Lagarto


  1. 2 hours ago, SrPx said:

    Actually you can work in CMYK mode in the pro version.

    Ok, based on your description it does not appear that Pro actually differs from EX in terms of color handling in anything else (just the PSD layer support). CSP (EX) is nothing like Affinity Photo or Publisher in areas of color handling and creating a publication for commercial printing, so there is no point in upgrading because of these features if one already owns Affinity Publisher.


  2. 7 minutes ago, pamchao said:

    I tried the oversampling method and it looked better. Let me know if this is somewhat correct:

    Ah, sorry, I actually just meant that from your original art (which was in vector format and already had a good-quality image of violin for the texture), you'd just first create a larger bitmap without compression, e.g. in PNG format (at least 5,120 x 2,880) but could well be over 10,000 px wide, and then open that PNG image (preferrably in Photo) and downsample it to the final size bitmap (in JPG format if you definitely need to have compact file size but otherwise in PNG format, since JPG compression is basically bad for gradients or subtle shift of tones / transparencies). 

    That resolves the problem with the vectorized letter edges becoming so sharp and jagged when producing the bitmap directly in final dimensions. Resampling down with bicubic method smooths (antialiases) the edges. If it becomes too smooth, you could apply a bit unsharp mask sharpening and finally check the levels (the most recent screenshot might be a bit too dark or contrasted, but looks generally just brilliant)! How large will the final art be (I assume it will be used only as web graphics, or are you going to print this, too)?

    I think you'd need to have Photo (or some other app for bitmap manipulation) for sharpening. But if you do not have it, it is not a big deal, the image looks jst fine as it is. Just compare the final image in PNG and JPG format and see if compression has (clearly discernible) negative effect, and use PNG if possible (considering the filesize).


  3. If you instead need to create web graphics of this, and keep file size reasonable, I'd use JPG at 85% quality setting. It would produce as 2560x1440 at 777KB, and would tolerate moderate zooming in:

    Symphony_Campaign4b.thumb.jpg.30be597762f56515a001a238cd5f06d1.jpg

    That would alleviate the problem of vector edges getting rasterized without antialiasing. They would be jaggy in any resolution when zoomed in beyond 100%, and I do not know if it can be avoided somehow. 


  4. Note though that the TIFF image used as the source of the texture for the "violin" building text, while itself a large enough bitmap, would get rendered at as low as 36ppi resolution if using a setting that allows resampling down of bitmaps (default when using 300dpi export setting would be placed graphics that exceeds 450 ppi).

    That is because the same image is used (it seems) three times as the texture of vector masks, and in some instances its placed resolution might exceed 450ppi, while in other instances not. If such an image gets scaled down because of a single instance, it would result in rendering warnings in instances where bigger resolution of the image is needed.

    Therefore there might be point in not allowing resampling down when exporting the final PDF for the printer. I tested exporting with the PDF/X-1a, which also converts the violin bitmap to CMYK, using the default resolution of 300dpi, and it produced a fine PDF that did not cause any resolution warnings, so I'd use this export format when delivering the job.

    PS. Nice constuction you have here! Did you create it right from the start in Designer?


  5. One thing worth noting is that if your document actually has imported lineart, then all Affinity apps would typically convert a 1-bit (monochrome) lineart to RGB format resampled at 300dpi (which can subsequently be converted to grayscale by choosing "K Only" button on the toolbar), so if the lineart initially has 1200dpi it would normally have 300dpi when exported (but should look just good, even if not razorsharp but rather a bit antialiased ACTUALLY the image would be resampled but not antialiased so it would look jaggy). Photoshop EPS format monochrome bitmap however would be imported at 600dpi but converted to grayscale. Pure monochrome lineart is not supported in Affinity apps

    UPDATE: Correction: For imported Photoshop EPS format monocrome bitmaps, the Resource Manager shows both nominal and placed DPI incorrectly as 600 dpi but what actually happens is that a monochrome bitmap is converted to grayscale but not resampled so e.g. a 1200 dpi monochrome image would practically retain its outlook and sharpness yet be converted to a grayscale image). 

    This is good to know if you expect to be able to use 1200dpi lineart. You can import (and export) bitmaps practically with any resolution you wish (e.g. photos, grayscale and lineart) but Affinity apps treat them all as min. 8-bit graphics so anything exceeding 600 dpi (and for most images: anything that exceeds 300dp) is practically not needed for creating a good printer halftone (as long as the sharp edges are handled by antialiasing them). 

    Because lineart is not in practice supported, there is also no separate downsample dpi value for lineart, similarly as there is e.g. in InDesign. That means that if you have a 600dpi export resolution set, and you have large enough photos placed in your document to be exported at this dpi value, you would get ALL images of your document exported at least 600dpi. That would make a big export PDF file, but unless you create page speific exceptional PDFs for just certain pages, Affinity Publisher cannot create/retain selectively high DPI images based on the kind of image (RGB/CMYK, grayscale, monochrome), but the setting would apply to all images in the document.

    Conversely, because there is not separate setting for "lineart" (or even "grayscale"), there is not point in placing e.g. 1200 dpi or 600 dpi bitmaps that contain lineart kind of pixel art, and expecting that they get exported at resolution higher than e.g. photos. The dpi setting chosen will be used for all placed bitmap image content (and when rasterizing vector art and effects), so when in InDesign you could export at 300dpi and still get 600 dpi grayscale or 1200 dpi lineart, this is not possible in Affinity Publisher.

    In practise if bitmap format lineart is needed, it is a good idea to downsample it at 400 dpi or so and use the exact size that is needed for output, and use antialiasation, since an alternative method (using standard 300 dpi exporting anything else, and a higher dpi for the lineart) is not readily available and requires a manual export workflow.


  6.  

    5 hours ago, AFY7 said:

    However, you can manually enter 600. In this case, does Publisher really export the PDF at 600 DPI?

    Yes, it would, but note that it would not resample e.g. images that have a resolution lower than 600dpi (ppi). You can see the resolution of imported images on the toolbar at the top of the document whenever an image is selected, or selecting Document > Resource Manager.

    What else gets rasterized, depends on the "Rasterize" export setting (shown when you click "More..." in the Export dialog box). Normally only features "unsupported" by the export format will be rasterized, e.g. fonts would not be rasterized but drow shadow effects would. 

    See below how PDF Preflight tool warns against using "too high" ppi resolution for two images: the flower in small size, and the shadow of the star: Both have a 600ppi resolution created by Publisher. The larger version of the photo of the flower (the image itself containing 1984 x 188 pixels), has been exported with its maximum resolution, 354ppi at its placed size, and is not resampled (that would be bad idea in the first place so Publisher behaves just right in not touching the resolution). However, the smaller version, which at its placed size has a resolution of 1126ppi, is correctly downsampled to 600ppi by Publisher, according to default export setting that tells to downsample images "Above DPI" value of 900 when creating the PDF (the value is scaled based on the defined document DPI by 150% and would accordingly be 450dpi for the 300dpi setting and 900dpi for the 600dpi setting).

    export_600.thumb.jpg.7c3a0c0e04ab301e4371a149d7c822f4.jpg

    So the answer is that yes, Publisher appears to be rasterizing the PDF in a way that is expected, but I have not tested the feature thoroughly (as there are infinite number of situations where rasterization is needed, or forced, that should be checked to ensure this). The important question is why your printer requires resolution as high as 600dpi, and is it actually required for all rasterized objects (photographs, e.g.), or just for some specific objects (e.g., line art, which at 300dpi would be too low, as lineart often needs to have 1200 dpi to not appear as jagged)? If 600 dpi is really required, you should check the resolutions ("Placed DPI" values, not the nominal or "original" DPI values of the image files which are irrelevant) of all your images by choosing Document > Resource Manager.

     


  7. On 11/10/2019 at 6:01 PM, APEGamer said:

    I tried importing a PDF created with InDesign, but it doesn't include the document bleed. Instead, I need to export from InDesign as JPEG files and open them separately in Affinity.

    First, please ensure that you have View > Show Bleed turned on in Publisher.

    Do you actually need to "import" (Document > Place) the PDF in a Publisher document you already have, or would you rather want to open the PDF (File > Open)?

    If you do the latter, you can specify the page range to be opened, and should have bleeds already correctly created (and possible inner breeds divided as separate object which can just be deleted if not needed, rather than needing to crop the art). After opening a PDF, you'd typically want to change the document units (File > Document) and ensure that the document has correct Facing pages setting. E.g., below a PDF with 3 mm bleed on all page edges has been opened, and the inner bleeds are separate objects (below the inner bleed objects has been selected, and the equivalent inner bleed of the next page is shown under the page).

    pdf_placed.jpg.1f18eae44b336c97d6f5da38109cfe0c.jpg

    If you do the former, then you should have a toolbox shown below, whenever you select the PDF placed in the document, and the possible inner bleed (shown below as yellow area), needs to be cropped with the Crop tool, if not needed in the layout. By default PDFs are imported cropped by the trimbox, so you'd need to choose "Bleedbox" from the list, and then typicaly reselect from the Spread box the page to be shown, to have the bleeds shown correctly. You can show additional pages from the same PDF simply by copying the selected layer, placing it in another location (e.g. on another page), and then select the page to be shown.

     pdf_import.thumb.jpg.bd6de8eb79548257bbe48aaa71229a7a.jpg

    You can use the two InDesign created PDFs below to see the different bleed scenarios, and how bleeds are handled when you "Open" or "Place" these files in Publisher. Both PDFs have an A4 format, contain 4 pages, have 3 mm bleeds, and have initially been exported from a facing pages document.

    ID_withinnerbleed.pdf

    ID_noinnerbleed.pdf


  8. Here's a tritone version. As far as I can see only the black part can be controlled by a live curve. If a grayscale image has PMS assignment, adjustments will turn the images to CMYK at render time. So the additional grayscales need to be separate grayscale files and be flattened after their curves have been adjusted in Photo.

    (Someone who knows Affinity apps throughout may find a way to simulate PMS inks on screen and yet have all inks with live curves, but if the PMS color assignment is directly applied on an Image layer, any curve adjustments (even limited to Gray channel) will make it render in CMYK.)

    tritone.jpg.39510fb0ba99ab04cb366f3e31c8d6ff.jpg

    a) Black ink:

    tritone_black.thumb.jpg.9a4d4e6dd114d6983202e3bae656f7db.jpg

    b) Warm Gray 6C:

    tritone_warm_gray6c.thumb.jpg.0047a4613f36b68ae4f267827e3db93e.jpg

    c) Warm Gray 11C:

    tritone_warm_gray11c.thumb.jpg.f1483e80d7458c6beb93134e943e71b9.jpg

    AFPub file and the PDF:

    tritone_example.afpub

    tritone_example.pdf

     


  9. There seems to need to make a conceptual difference between "simulation (of production)" and "fake". The example given above was not a faked duotone in the meaning described by David Blatner, as it combined two grayscale screens, and not a uniform layer of a PMS tone under the black ink. The examples in the original post (referred in my first post in this thread) were indeed faked duotones where the uniform overlay method exactly was used (and also clearly shown), but in the same thread we also discussed the possibility of using multiple grayscales with adjustment curves to create true duotones. The example above is a “true” duotone, but as curve and ink control is very limited, it is better to call this “simulated duotone”, or something like that.

    Also, as mentioned in my post, the PMS part could well be taken to Photo and handled directly, without an adjustment, to control how the spot color part is distributed, to make it yet more "true".

    It is up to the skill of the user who applies the curves for the two inks they choose to use for the effect, whether the result looks like “piles of mud” on the paper, or something more sophisticated, but the technique is there, even if crippled. The image above was just a demo, but I guess most printers can produce more than mud of a pretty linear screen of PMS Warm gray accentuated with black.

    But this is of course a bit constrained way of producing  duotones, and I'd definitely stick with Photoshop and InDesign if I were to actually print anything in duotone.

    The screenshots below illustrate the difference of true and fake duotones, and a Publisher demo is included, as well, and a pdf.

    duotone_testcurves_true_fake.afpub

    duotone_testcurves_true_fake.pdf

    Inks combined:

    true_and_fake_combined.thumb.jpg.e328334dd01b92d6e0081b9d2b86ec17.jpg

    The PMS part:

    true_and_fake_pms.thumb.jpg.0f9af76265105627923a194ed2b9b025.jpg

    The black part:

    true_and_fake_black.thumb.jpg.49935d450ecb72c512db573476a969ab.jpg


  10. You can do something like this in lack of the real thing:

    duotone.jpg.c9a7da9d5f206b66610fa60e966ad07f.jpg

    duotone_black.thumb.jpg.ac4c0500ccba4de582e9ca9a1c9dfd3b.jpg

    duotone_warmgray.thumb.jpg.2a42ec726972c4f910bf82b68c2d6621.jpg

    That is, you can have black grayscale version with curves and levels (on gray channel) on top of the PMS version. I think that the PMS layer cannot have adjustments applied, at least when I tried it turned to CMYK (but you could of course process a grayscale directly on pixel level and save it as a separate image). 

    I do not quite understand the logic of this. Sometimes I think i need to turn PMS to K100 and back to PMS to keep it a spot color, and it seems that applying the gray curve on the black plate helps the top layer from converting to CMYK. 

    The PMS has overprint defined but it has no use here (as the spot color is the bottom layer). As the top layer has Multiply blend mode on the total effect can be approximated to some extent.

    Attached are an Affinity Publisher document and a PDF. (Note that the Publisher doc is created with latest beta so latest Photo beta is needed to open it.)

    duotone_testcurves.afpub

    duotone_testcurves.pdf


  11. 6 minutes ago, Fixx said:

    It might be possible to create two greyscale versions (with appropriate curves) of the plate and set them over each other and set upper one to print with Pantone and overprint. I though think this is too hard an exercise to be used in normal production.

    Yes, that's what is done in the referred post but as you mentioned, it is really just playing with curves without proper control.


  12. Those internal parts where something that i initially missed and then just used the flood selector without refinement to cut them out so they are worse than the outer edges where refinement was applied. I have not used the selection tools of Photo long enough to use them effectively and they work a bit differently than in Photoshop (where the combination of shift edge, smooth and contrast help you create perfect cut-outs for these kinds of objects with uniform background) .  


  13. 13 hours ago, R C-R said:

    I doubt this is a price most designers really are ready to pay.

    I am not sure if this was an argument against implementing similar (optional, user decidable) nudge behavior in Affinity Designer, as is provided by the competition, or what, but I trust that most users are capable to decide where and when to apply forced pixel alignment, and understand the cost. 


  14. 14 hours ago, Lorox said:

    Exactly, I'm completely with you here. Applies to me 99%. 1% is for – very rarely – being able to fix certain problems (like reducing unwanted color density caused by quirks in the PDF’s creator sortware) which cannot be addressed by making changes to the document within the app it's been used to create.

    The Output Preview window is obviously useful and the Preflight tools give a concise report and easily reveal e.g. TAC and other ink-related problems especially in 3rd party stuff (e.g., use of spot colors in ads, and you can use its single fixes instead of needing to ask a new version or do manual editing). But most of the things can be checked by using InDesign internal preflight and Output preview, and i hope that similar devices will be offered in Affinity apps in the future (it helps a lot that they can open PDFs they have produced, so certain basic things like color conversion problems and unexpected rasterizations can be checked this way, too). 

    Many things have changed along the time print files have been delivered using a pdf (export) based workflow, and use of color profiles and standard export methods allowing mixed content have made things easier (even if sometimes more confusing). On the other hand, i am not sure if I could do without Acrobat Pro (as it has many other uses, too) so for my part the answer to the topic would be Adobe Acrobat Pro 2017 (and wishing good luck that it will run long enough to become a bargain; the package itself provides probably enough preflight power to be useable for a lifetime of a regular graphic designer; PostScript based technology is soon 40 years old, it evolves and is not going to fade away from the industry -- PDF and standardized export methods are made to last). 

    14 hours ago, Lorox said:

    have been some problems and concerns with/about full compliance to current PDF standards. I'm not sure if these have been sorted out yet.

    So it has been reported but I do not know what things exactly have failed. Current lack of support for PDF passthrough is the biggest issue with Affinity apps, and might explain some of the problems with compliance checks. However jobs that are created directly with Affinity apps and imports that are fully controlled by them (opened, checked and edited as needed) seem to export just fine as print PDFs, especially when using standard modes. I have tested opening complete, complex print pdfs (e.g. magazines) created in InDesign (using PDF 1.4 based regular CMYK export), and exported them from Publisher by using PDF/X-1a and PDF/X-4 standards and checked their PDF/X compliance with Adobe Acrobat Preflight tool verifiers, and none have failed so far, and detailed Prepress tools give exactly same trivial warnings as they give for original pdfs, so I am fairly confident that Affinity apps do deliver once the documents are properly created.

    I suppose  that most of the PDF export and print production problems experienced by Publisher users are related to improperly created documents (wrong color spaces and color assignments, inadvertently performed color conversions through Document Setup, unexpected rasterization due to failure to mask an effect), placed pdfs and vector graphics (with an expectation that they could be passed through but when not, appear more or less broken, fonts replaced, missing or misplaced elements, etc), use of  wrong export settings, etc. It would be good if there were some in-app guidance or at least stickies on the support forum to recommend robust workflows and list common mistakes. There are also confused settings and many UI issues that cause e.g. inadvertent color changes and rasterizations so the apps have a lot to improve.


  15. 18 hours ago, R C-R said:

    Basically, they cheat, selectively changing some combination of the position, size, or stroke alignment of your shapes to fit into some algorithmically determined 'nearest' whole pixel values.

    Only nodes will be aligned so strokes are irrelevant. It is for the user to see that strokes are pixel-defined, not used at all, or are inside aligned, and that the shapes have widths and heights defined with whole numbers (if possible at all). If the objects are complex and do not themselves have widths and heights defined in whole numbers, it is often not intuitive how nudge will be applied (as e.g. in Illustrator it tries to first apply at least the user-defined nudge distance -- it does not even need to be pixel based, or a whole number -- and only then calculates how the object should be placed so that its nodes get aligned with the grid; moves may be "jumpy" and quite different in different directions, and subsequent nudges can move the object in different increments, because moves are rounded up to guarantee the minimum nudge distance, and a different node might be used as an anchor for grid alignment in successive nudge operations.

    It is straightforward when you have objects like pixel aligned rectangles, which are not positioned pixel aligned: e.g., a 1 x 1 px rectangle at 1.2 x and 1.2 y (top left node) would be aligned as follows, when you have 0,1px defined as the nudge distance (to force alignment to nearest pixel): left (left edge would be at 1), right (left edge would be at 2), up (top edge would be at 1), down (top edge would be at 2). After that, each nudge would move the object exactly 1px in the direction of the arrow key.

    However it is not clear what should be done with single nodes. In Illustrator the "first nudge" principle will not be used for all kinds or individually selected nodes, but only for nodes defining line segments, nodes with handles seem to be always moved by the distance specified by the nudge setting, instead, and not aligned, even when the grid is turned on..

    The point is that the arrow keys work as tools that help getting nodes aligned when the grid is turned on. In Affinity apps this could well be implemented via Alt + key operation, in which case single nodes no matter what their kind is, could also be moved by the same principle, if the user chooses so. 

    I would be happy to see this operating with all kinds of grids and units (similarly as in Illustrator), not just with pixels.

     

×

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.