Jump to content

Lagarto

Members
  • Content count

    599
  • Joined

  • Last visited

Posts posted by Lagarto


  1. 13 minutes ago, Franzi von Fragenfeld said:

    Btw.: How would you convert the images manually in Publisher?

    There is no need, if you use PDF-X-1, or convert color spaces by manual export setting but when using non-X-standard based conversion, you need to be careful to have the same ICC destination color profile as your document color profile. Otherwise you end up converting also colors that already are in CMYK color space, and this results e.g. that your K blacks become CMYK blacks.

    I would not perform any kind of color conversions within a publication. If you want to import CMYK images in the first place, I would import CMYK TIFFs. But there is no point in that.


  2. 15 minutes ago, Franzi von Fragenfeld said:

    Btw. They state specifically that Word and so on do NOT produce suitable pdf's...

    Ok, so it is not that. I checked one German site at http://www.promo-druckerei.de and they basically expect everything to be in CMYK (based on templates they provide). I uploaded there your test.pdf and it did not cause any warnings. Can't tell though what kinds of checks were performed...

    But if the printer you are using has a service that can be used without any account for uploads, I could test and see what they expect... 


  3. 3 minutes ago, Franzi von Fragenfeld said:

    so, resulting from my test to submit with the Acrobat 1.7 profile I still got the "no color profile embedded" back from them. That despite setting the color profile in export as PSO Coated v3.

    Is it an automated check? This could also be indicaton of a process where printer expects all images to be RGB images containing sRGB color profiles and then converting all stuff to CMYK based on document color intent. So its complaints might be related to source color profiles. (This could e.g. indicate a printshop that typically expects PDFs created from apps like Word, etc., which do not handle CMYK at all.) 


  4. 37 minutes ago, Franzi von Fragenfeld said:

    On a side note, I think Affinity should not make it more obvious that images do not get converted when specifying X4 as the Pdf type. Not all of us work predominantly print and are aware of that.

    It can get quite tricky. Many printers might specifically ask for PDF/X-4 yet assume that all colors are already in CMYK, see e.g. 

    https://www.livoniaprint.lv/services/pre-press#indesign-settings-for-exporting-files-to-pdf-2

    ...which is a printer that is much used e.g. in Finland and Sweden. I do not think that it is even possile in Affinity Publisher to define PDF/X-4 and have color spaces converted. In InDesign it is.

    So if the printer expects to have colors in CMYK, I would use PDF/X1, which converts your RGB stuff to CMYK according to your document color profile (PSO Coated v3), does not leave transparencies unresolved, and keeps your K blacks as K blacks. If you use manual settings, you may end up converting your K blacks to rich black (you must be careful not to specify destination color space the deviates from your document color space).

    As a general note, you should always create the Publisher document with correct document color space and then just import your RGB images etc., and NOT use the Document Setup convert feature. That would change your K based texts and would also have effect on imported images. The feature CAN be used but with great care so that there will not be unwanted changes. Especially all black texts should be checked thereafter so that they do not have unwanted CMY components. (NOTE: This warning applies if you CHANGE the document color space using this feature; just opening the dialog box and keeping the settings, will not do anything.)

    EDIT: The link above also illustrates the situation, which hopefully will eventually change: the printers assume that workflows are InDesign based. The InDesign users are not necessarily any wiser, or InDesign any more helpful in choosing the correct settings (well, it actually IS, but information is useful only if the user understands the basics of color management), but they get detailed instructions from the printer.


  5. 45 minutes ago, Franzi von Fragenfeld said:

    Should not all images convert automatically to CMYK if I set that as export color profile?
    In my view thats the purpose of setting a color profile on export.

    No, in PDF/X-4 method the default is that color spaces are not converted, and that's why the profile and intent-information is included. PDF/X-4 also leaves transparencies etc. unresolved.

    In PDF/X-1 the colors are converted to CMYK and transparencies are flattened, so it basically does not leave anything unresolved, and does not need to have profiles embedded. 


  6. You could just add a page and enter there e.g. some text (preferrably one text box with C0M0Y0K) and then any small portion of any image (RGB, CMYK, whatever) that represents how you have imported images in the document. This would be enough to check that your K definitions do not turn to rich black and that your RGB images get appropriately converted to CMYK, and that you have the color profile embedded.


  7. 1 hour ago, MEB said:

    there's only three modifier keys available. macOS provides four.

    Yes, I understand, but as Ctrl is "free" in this context, and as you can also combine the modifiers (e.g., use Alt + Ctrl which I think is not often used in Affinity apps), I hope this could be re-considered at some point (or made an option on Windows: use Ctrl + Alt instead of mouse right button combination), and the mapping at least would not be made as mechanically and categorically as now (to me this appears to be "macOS first" principle, and right mouse button only added as an afterthought). Though this is of course also a matter of opinion, and a personal preference, some users may prefer the two mouse button configuration (e.g., in this particular context, it could be considered "intuitive" because it in a way imitates symmetry) -- so therefore, hopefully this will be made as an option.


  8. 29 minutes ago, MEB said:

    The shortcuts i gave are for Mac. Didn't know the user was using Windows. Should have posted for both OS. And no, these are not configurable.

    I wonder why there is a different operation on Windows? Pressing both mouse buttons down is pretty awkward way to control anything, and quite uncommon and unintuitive for the platform. As Ctrl seems to be without any function in node operations, it would be far better to have this working similarly on Windows. If there really is some secondary operation reserved currently for the Ctrl key in context of node handling, then perhaps that could be assigned for mouse left + right, instead? 


  9. 6 hours ago, lserpes said:

    Thanks for the answer, but couldn't solve it.

    To move control handles symmetrically in oppostie directions: click either control handle with left mouse button, and while keeping the left mouse button down, press down the right mouse button, then drag. As long as you have both mouse buttons down, the control handles move symmetrically.

    To force a smooth node symmetrical: use the Pen Tool (not the Node tool), and click the node that you want to make symmetrical, keep on holding down the left mouse button and drag, and the control handles move symmetrically.

    In both cases you can constrain the angle by 45 degrees increments by holding down the Shift key.

    5 hours ago, MEB said:

    press ctrl while dragging one of the handles to make both longer or shorter at the same time

    I cannot reproduce either of the mentioned Shift+ Ctrl operations. Instead, pressing down left and right mouse button forces this behavior (at least on Windows). Perhaps this is configurable?


  10. I had a look on this in Publisher, and based on my tests, it seems it is better to have the document created with CMYK/8 color space and the correct profile (e.g., in the United States, US Sheetfed Coated would be typical while in Europe Euroscale Coated 39, ISO Coated v2, etc. are the most common profiles for coated paper) right from the start, and import the Greyscale D50 images only after that. It is important NOT to change the color space after you have created your publication document and specifically not after you have imported your images. Greyscale D50 is basically a display color profile (with 255 gray values) and must be converted to percentage values of black ink and the correct printer profile adjusts the percentages so that the dot gain typical for the kind of paper you use will be considered so that the images do not print too dark

    If you use Greyscale document colorspace in your publication document, you'd also need to pay close attention to the export settings, since you may end up inadvertently converting your grayscale images to CMYK images as I noticed that some export profiles will force conversion from grayscale to CMYK even if conversion of color spaces is not specifically asked. But having the document color space right from the start as CMYK/8 and then exporting with e.g. PDF/X-4 profile, would keep the images as grayscale (and use mere black ink to print them). PDF/X-4 is just one export option, please ask your printer if they have a recommendation for the PDF export method. 

    I think you'd need to use Publisher for this job. Designer is an artboard based app rather than a page layout application.


  11. 45 minutes ago, Luko said:

    are you saying importing the Greyscale D50 images into Affinity Designer (also Greyscale D50 profile) is not the best "practice"?

    No. If you have the color profile recommended by the printer in your Designer document and import your grayscale images with Greyscale D50 profile embedded (and have checked that the shades are ok already in Photo) then it is up to Designer to make any adjustments related to the kind of paper you use (this happens when you export to PDF according to the document color profile). I do not think that Affinity apps support Dot Gain based gray scale conversions so going with the Greyscale D50 is ok. If your display shows colors and grays realistically enough you should be able to trust that you get more or less what you see even without a calibrated display.

    45 minutes ago, Luko said:

    The images seem very flat after the conversion. I use a Black and White Adjustment layer before flattening and converting to Greyscale D50.

    After having used the Black and White adjustment layer, I'd use Levels adjustment to get the shades, highlights and mid grays balanced. If you convert from color photos, the Black and White adjustment layer allows you to selectively bring up or down converted grays, but these adjustments may be highly dependent on the kinds of colors that exist in the original photo, so you may need to spend some time with them to get a good conversion.

    If you are uncertain about the levels, you can upload here on the forum a sample of gray conversion you typically have (in file format you intend to import in Designer) -- e.g. of some generic photos and not necessarily any of your actual photos of people, but just something that represents well the typical gray levels you have in your images after the conversion.  

    EDIT: I just realized that you mentioned that you have Greyscale D50 as your document profile also in Designer. I think it would be good idea to ask your printer if they rather want you to have some generic or specific CMYK profile for coated paper, even if you'd produce the color parts in a separate document. (CMYK profiles are normally used in commercial press even if you print only by using the black ink.) 


  12.  To add a node at the middle of the vertical or horizontal line segment, I have not found other means than first dragging a guide, as it snaps in the selection (bounding) box middle point. Then the node tool snaps in the middle point, as well. I do not think that there is equivalent to e.g. CorelDRAW's plus key (or Illustrator's Object > Path > Add anchor points), which can be used to add a new node in the middle of two control points defining a line segment.

    To move handles of a smooth node symmetrically with equal distances hold down the left and right mouse buttons while dragging (shift to constrain at 45 degrees angles). Note that if the node is not symmetrical, dragging this way does not make it symmetrical, either. To convert a node symmetrical (or at least behave as if it were symmetrical, as I do not think there is actually a symmetrical node type in Designer), the way I have done this is using the Pen Tool and clicking the node to be converted and then dragging (and holding down the shift key to constrain).

     


  13. Just to make sure: when you view the gradient.pdf that I had produced, did you see banding there, as well? Which app do you use for viewing pdfs? If you open a pdf that looks banded in you Affinity app, does it look banded?

    UPDATE: I re-read your original post and as you mention that JPG gradients look just fine, as do gradients when you edit them, there does not seem to be any problem with your display, so the crucial question is how you view your pdfs, and whether you see the pdfs created by you and me from the same source differently, and whether a PDF that looks banded still looks banded after you open it in you Affinity app (Publisher, I assume)?


  14. As @thomaso noted, it may be a good idea to leave the rasterizing setting to its default and only rasterize the features that are not supported.

    However, you had exported the pdf with quite high resolution (400 dpi), and it would produce perfectly good gradient on print. I could not see any clear banding in your original post, either, so I wonder if this could be a thing that only shows on your screen?

    Please visit http://www.lagom.nl/lcd-test/gradient.php and see if you can experience any banding effect on your screen when running these tests.


  15. 1 hour ago, R C-R said:

    To get rid of the streaks, a mask or clipping an appropriately sized shape to it could be used, & then the result could be duplicated & manually placed to create a repeating pattern of a sort, but it is a clumsy workaround at best.

    Yes, but I just wonder if this is an oversight in the code. I cannot see any reason why the pattern could not be repeated within an area defined by pixel layer similarly as it can for an area defined by a vector shape (the pattern is not e.g. regenerated if the shape is resized, but simply just scaled, smilarly as when it would be mechanically duplicated on a pixel layer to create a fill).

    See below examples of the pattern repeated by using the Photo gradient fill tool applied on a vector shape (and exported as a PNG bitmap), and fill created in Photoshop by using the "define pattern" and "fill with pattern" feature (which is a pure pixel copy operation from one source onto another). In both cases the same small pattern bitmap, created directly from the original graphics without any consideration on how well the defined area repeats was used (but in Photo I could not find a way to ensure that the pattern is not scaled so its size is only visually approximated to be 100%).

    patterns_compared.png.efde8525d325dc1acde04637c8c572bc.png 

    Note that the Photo version has been re-created completely while the Photoshop version uses the original screenshot and only has the gray fill replaced with the pattern.


  16.  

    15 hours ago, marco_chacon said:

    So--I am not a Blender expert--but you can use the bit-map in the software and I may do exactly this. Blender is a great tool and you would not need to use Bezier curves to do the walls, etc.

    If your goal is anything like this I’d say it is a good idea to create this in Blender, right away. I just wanted to comment the huge development in the industry where advanced tools have become available for anyone, and how there is constant need to learn (again) things but only limited personal time, so in order to be efficient you can save some time by picking the right tool, and really do not need to create something like this with a pen tool! But fluent curve handling of course needs to be learned sooner or later in Blender, too, it is the ABC of creating anything in vectors even if you are not forced to draw curve elements in many projects. 

    Whether you create your technical drawing primarily with Bezieres (closing them when needed), or rectangles and ellipses -- or by using mesh primitives, if you’re creating this in a 3D app -- and then shaping them, depends on the kind of drawing you need to trace, but often it is best to create the elements manually. An inaccurate bitmap is not a good starting point for automated tracing, especially as you typically need to spend some time cleaning it, and trying with different tracing settings before finding ones that produce a good starting point for the vector drawing. It is often a frustrating workflow because you end up cleaning mathematically rendered inaccuracies (e.g. removing superfluous nodes, straightening lines, aligning nodes, etc.)

     Sometimes the sensible method is simply to clean and keep the bitmap and make any necessary enhancements there (and overlay the bitmap, if necessary, with vectors and text layers), and sometimes tracing manually from the scratch. But in some cases using a tracing tool (not available in Affinity apps, though) really can produce good results in little time, but preparing the job and choosing proper settings is a specific skill, as well.

    In this particular case a good approach really could be creating first a clean simple SVG file with Affinity Designer and then use the plugin to create 3D primitives.

     


  17. 45 minutes ago, marco_chacon said:

    but then what?

    You would place the bitmap on the artboard, lock it (and possibly making it a bit lighter by using an image adjustment), then use the Pen Tool and start clicking the nodes to define the shapes of the underlying bitmap, considering where and when to close the shapes (this depends much on whether you need to fill them afterwards). When you get experience on this, you can basically create only the truly defining nodes and create the kinds of nodes (cusp, smooth, etc.) that are required to define the shape while you click in one go, but as Designer allows easy shaping of segments simply by dragging them, you can easily change line segments to curves. Learning to use the constraints and snapping properties (to keep lines vertical and horizontal and to get objects to align to each others) is an essential part of the process. But once learned, these kinds of tracing tasks are pretty fast to accomplish.

    If you are not experienced with the Pen Tool just click around the shapes to coarsely encompass their width and height and major slopes with straight lines. Once done, drag and bend the lines to convert them to curves so that you get the shape defined more precisely and finish by dragging the control handles. If the underlying shape is not accurately enough traced, add new nodes as necessary. Often this is more efficient than trying to trace accurately (by creating right kinds of nodes at the time the nodes are created), but this of course depends on the kinds of objects that need to be traced, and the amount of experience you have on the tools that you are using.

    tracing.jpg.26ef8136142988cfe4b4cf3bcb80be2d.jpg

     

     


  18. 19 hours ago, Cyranose said:

    DRAG IT OVER THE LEFT BOUNDARY! 

    This would work otherwise nicely but there should be a way to reliably constrain flipping to original width and/or height. CorelDRAW does this similarly for vector objects and allows constraining but I tried all snapping settings available but could not achieve snapping to original size, or e.g. based on the underlying clipping transparency.

    UPDATE: Just checked this, Corel PHOTO-PAINT does this for bitmaps, as well. 


  19. I can reproduce this. Strangely it only seems to happen on a page or spread that is currently in focus at the time the format preset is changed. I added two pages after the last page, made the new last page active and changed to A5 preset, and no changes in the layout.

    Before doing that, I had changed the document units from pt to mm (File > Document Setup), and also specified the document to be "Facing pages" as without this elements crossing the spine do not show properly.

    So this seems to be a bug, but one for which there is an easy work around.

×

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.