Jump to content

Lagarto

Members
  • Content Count

    2,379
  • Joined

  • Last visited

Everything posted by Lagarto

  1. Affinity apps do limit TAC when performing color conversions at PDF export time, which can easily be seen if the attached.afpub document with ISO Coated v2 (ECI) (basically a TAC330 profile) as the document profile is used to export to e.g. ISO Coated v2 300% (ECI) (TAC limit 300), or ISO Newspaper26v4 (TAC limit somewhere around 230). a) No profile conversion, so no TAC limit: b) Conversion to ISO Coated v2 300% (TAC limit 300%), mouse pointer at the intersection of CMYK circles set to overprint, so defined TAC 400, actual coverage 273%): c) Conversion to ISO Newspaper26v4 (TAC limit somewhere around 230%), mouse pointer at the intersection of CMYK circles set to overprint, so defined TAC 400, actual coverage 178%): I have no clue whether color reduction methods like GCR and UCR are properly applied but when I exported an equivalent test file from InDesign using the conversion option to not preserve colors, I got nearly identical results both for TAC limit and color values of overlapping overprinting CMYK circles. When the document profile is not changed, TAC limit is not applied (if the color space is the same, but e.g. for RGB images that are specified to be converted to CMYK, it would be applied), but that is as it should be (and this is how it is also when exporting from InDesign). In Affinity apps it is not possible to switch color profile at export time without causing remapping of colors and applying TAC limit, in InDesign this is possible if "Preserve Numbers" conversion option (the default) is applied (in which case the target profile is simply just assigned). So it would appear that it is technically possible to e.g. convert to TAC240 limit profile without making changes to the document objects, but whether this can be successfully be used e.g. for jobs without a proper ICC target or recommendation (or when stock is not close to one for which the ICC profile was initially designed) is of course unsure, so especially for images I would prepare conversions separately and preview the changes and adjust if needed (manual ajdustments are often needed anyway when printing the same document for highly different stocks so we practically always prepare separate version e.g. for newspapers) . tac.afpub tac_isocoated_330_w_imageconversion.pdf tac_isocoated_300_w_imageconversion.pdf tac_isonewspaper_w_imageconversion.pdf UPDATE: As shown in the demo, doing on-the-fly color conversions is not recommended if the user has no clue what happens in the conversion. E.g., K100 definitions (typically text) will be converted to rich black unless the black is specified as a spot color, and such arrangements are not necessarily ok by the printer and should at least be negotiated before delivery. So if a publication has objects or images that exceed the recommended TAC, and the recommenation is as low as 240, it is definitely better to always prepare manual conversions and color definitions, if color is at all critical for the job.
  2. If you'd have this kind of situation (separate polygons aligned by their definining nodes and having stroke colors defined): ...then you could swap stroke and fill colors shape by shape by clicking the black curved arrow button in the Color Panel (or by pressing Shift + X), but I think you'd need to do that for each shape separately. I do not think that there is a shortcut for just copying fill color from stroke or vice versa. But you could have a copy of colored outlines placed on top of colored fills to have both.
  3. I am not sure if I understood your technique or what you are trying to achieve, but if creating perfectly aligned polygons, there might be point (so far in lack of Illustator kind Shape Builder Tool) in creating them by using Boolean tools (e.g. adding, subtraction, intersection and division). On the other hand, if you need to align separate already existing shapes manually, line segments are best aligned by using nodes, so I would just align the polygon shapes using the node alignment, then define fill colors for each separate shape and finally select all shapes and remove their strokes. But if you already have aligned abutting shapes visually by their (middle or outside aligned) strokes, or if you need to have shapes partially overlapping each other, it might make the job a bit smoother if you first define colors for the strokes, then expand them in one go (Layer > Expand Stroke), then separate the strokes (Layer > Geometry > Separacte Curves), and finally delete the redundant residue shapes from the middle of polygons.
  4. I am not sure if I understood what your problem is but you can have decimal tabs both in tab-based table and a true table. a) Tab based table (here you specify decimal tab for each tab separated column): b) True table (note that the tabs specified as part of paragraph definition are defined in relation to the cell; tab characters need to be entered manually; at least on Windows, there is no text ruler that could be used in context of table cells so you just use the Paragraph panel to enter the tab positions and alignments): If you paste from Excel, you probably get tab separated text (though on macOS, you might get a true table, similarly when importing tables from Word).
  5. Yes, I am not sure if it is meant to be but it can be considered as a kind of "constraining". In CorelDRAW Ctrl is used to constrain the scaling and Shift is used for mirrorring (flipping) from the center, which I personally like better. But if you want to flip horizontally you need to do it as a separate step using the side handles.
  6. I think the most common meaning is though (in print industry and graphic design) an 8-bit (or 16-bit) one-channel bitmap (plus possibly alpha, duotone etc. information), which basically should not be rendered in multiple inks (CMY colors) in any condition (other than when used for tinting). The problem with Affinity apps grayscale model is that it is not well suited for CMYK based print production. D50 (the only grayscale profile that comes with the package) is not color managed in a sense that different stock (newspaper, coated and uncoated paper) would be properly handled when using grayscale images. D50 images gray values are just passed through without color management, and when color conversion happens at export time, they typically convert to four-color grays. E.g. in the "Katze" image in OP's document a 16-bit grayscale image with D50 embedded had K100 definitions for strokes, but their grayscale representation is G14 (as K100 is first translated to RGB and then to equivalent grayscale value). On the other hand, the Flugzeug image, also a 16-bit grayscale image with D50 had G0 defiinitions made to the strokes, which in Affinity is same as RGB 0,0,0, and translates as C100, M100, Y100, K100. So in one grayscale image K100 translates to G14 and in another G0 translates to registration black or pure RGB black. This is pretty absurd for anyone who has done page layout with apps like InDesign or QuarkXPress. There are ways to deal with this, but one could say that the user will get as a bonus gray hair in the process...
  7. Holding down the Shift performs horizontal flip WHILE you in the same process have first flipped vertically (by dragging over).
  8. Not really. It has that mysterious U.S. Web coated profile embedded which always happens when D50 based grayscales are exported to CMYK PDFs, so its probably Affinity internals working in a way that keeps a grayscale black as K black. This probably works ok if the whole job is done similarly but I'd feel quite insecure mixing these in a job that also has colors in CMYK even when exporting using PDF/X3 or X4 with all involved color profiles included. I was too tired yesterday to have a proper look on this, but examined it closer now. You are absolutely correct, it should not be this difficult to keep grayscales K-based in a CMYK job. Here are some further comments: 1) As already mentioned, the file has both grayscale (16 bit) and CMYK files linked in a CMYK document, and the mix easily results in generation of four-color blacks at export time. Linked b&w/grayscale files behave as expected only if they are monochromes (which Affinity apps do not support), or if they have profiles such as Dot Gain % profiles from Adobe embedded (rather than D50, which is basically non-color managed in CMYK jobs); vector objects should preferably be defined in CMYK. An easy workaround is to try to force grayscale conversion at export time, but this is not always possible (e.g. when the same job or pages also have objects that are wished to be printed in four color). As I tried this, this worked ok but the barcode showed mostly gray 86 values instead of K100 so conversion was done for this object even when using D50 document color profile in the publication. The other graphs stayed as K100 (and grayscale fills at points where defined). 2) The other method, and one that requires much more work, is to keep the document as CMYK file and make changes to individual files: a) 2RK - grau with Coated Fogra 39 has four-color black strokes defined, but can be easily converted to K100 by selecting all strokes and making the definition. b) 2Katze Skizze - grau is Grayscale/16 with Grayscale D50 profile embedded can also easily be converted to K100 by first converting it to CMYK/8 (with Coated Fogra 39 profile) and then defining all strokes as K100. c) Flugzeug mit Strahlen - grau is also Grayscale/16 with Grayscale D50 profile embedded, and should be converted to CMYK/8 and then define all strokes with K100 and a few fills with K100, and one with K50. The picture has a bitmap mask that causes the rays to become rasterized. The bitmap mask should be replaced with a vector and as cutting may be problematic I would just place a curve with white fill in the middle to cover the parts of the rays that are not wanted. The ray strokes should also be defined as K100. d) Barcode 3 - grau is also Grayscale/16 with Grayscale D50 profile embedded and it has complexity that causes the graphic to become rasterized. It could perhaps be fixed with careful compositional changes so that the graphic stays in vector format but I would convert the picture to a high resolution grayscale bitmap possibly thresholded and exorted to TIFF with black and white profile and then also export the page where the barcode is included separately with high resolution (e.g. 1200dpi, not allowing downsampling). I prepared an .afpub file and a CMYK PDF in the process so I can post them privately if you are interested.
  9. As @thomaso mentioned, having in the same document both grayscales (and especially with D50 profile which is a display profile and needs to be forced to be exported as grayscale to be outputted in just K) and CMYK images is problematic, so if you prefer to have the book produced with just one PDF export, I would make all the grayscale drawings CMYK drawings (and see that they share a common CMYK profile) and define the black in K only. There are also problems with masks that cause the vectors (e.g. airplane "rays" and the barcode) to become rasterized, and when they do so, they turn to four-color grays. Another option would be to export just these problematic pages forcing them to be converted to grayscale.
  10. You have CMYK (four-color) definitions in strokes of your drawings (the airplane has also a few four-color fills): (image removed as per request) Once fixed, the drawings export as K100 just fine. (image removed as per request)
  11. One way this happens inadvertently very easily is if you grab the middle bottom handle and drag it over the top of the text frame and hold down the Shift key while doing so. (Dragging over flips the text vertically and holding down the Shift key flips it horizontally.)
  12. You should be able to find out the original size of a resized pixel layer by scaling the resized object until it reaches the document resolution: a) First check the document resolution from Document > Resize Document: b) The transformed pixel layer shows here the horizontal and vertical dpi values of 22 x 13 dpi: c) Straighten the object and resize it until you get the document dpi value (72 dpi) expressed as a single value in the DPI box: In this case, the original dimensions of the transformed pixel layer were 118px x 118px.
  13. That's it! I searched if from Photo! But found out the way to get this information there, as well, so worth an effort!
  14. Found out another method, also available in the current release (and probably any earlier) version of Photo, also on Windows. Just scale the image until the document DPI value is shown as single value in the dpi box (at the top left):
  15. I tried to find out where this information is shown but could not spot it in the current Windows beta -- perhaps this is implemented so far in macOS version only. One way to find out the original widh and height of a pixel object is though available also on Windows, and also in current release (and probably any earlier) version of Photo, is to copy a selected pixel layer on the Clipboard and using a clipboard viewer to display the PDF version of copied content. It shows the original image width and height of the bitmap object: Saving the content to PDF and then opening it in Photoshop confirmed that the two pixels more in both width and height dimension are a margin added by Affinity when placing the object on the Clipboard, as trimming away the transparent edge pixels resulted in image 423px wide and 331px high. This would be a very useful feature if available directly in the UI so that a pixel layer content can be reverted to its original size simply by using a menu command or similar.
  16. Ok, thanks. I did post it initially there, I have not posted for a while on the bug forums and I did not remember that there is a separate area for the beta versions.
  17. I thought that I posted it in here. Is there a way to see where a topic was originally posted, or if the original forum is changed by a moderator?
  18. Trying to export a publication that has a placed PDF marked to be passed through using any of the PDF/X methods (PDF/X1a:2003, PDF/X3 or PDF/X4) causes immediate crash of the app as soon as the option is selected from the drop down. I have tried this with a couple of documents and it seems to happen with very simple files, as well (see the attached files). Testptpdf.afpub testpassthrough.pdf PS. Thanks for the feature, I did not expect this to happen pre v2!!!
  19. Yes, depends of course on the text editor. On Windows Visual Studio can handle the line breaks without problems while Visual Studio Code (oddly) cannot (even after it asks whether it should fix line breaks). Notepad++ shows PS but not does not break the line, many HTML editors, even the old Microsoft Expression Web can handle the line breaks.
  20. Yes, this is badly needed. The paragraph breaks come now as Unicode paragraph separators which when pasted as Unicde text show in many apps as PS or PSEP and when converted to ASCII/ANSI as question marks.
  21. IMO the color palettes need a complete rewrite both what comes to functionality and user interface. I was mainly referring to the challenge of having the three different apps integrated. Palettes in InDesign, Illustrator and Photoshop are quite different for a good reason so if the goal is to keep things uniform, there is probably some cost the users have to pay in usability, and for this reason I do not expect the Affinity palettes to ever behave similarly as palettes in equivalent Adobe apps. But they are horrible as they are now. Color management requires documentation, first of all, and then proper controls that make the procedures explicit and logical, plus a couple of useful features (e.g. possibility to determine whether pasted objects with conflicting color profiles will have color values retained or translated). But this will never become an easy area for most of the users -- Adobe users have the benefit of being offered most of the time step-by-step instructions (and often templates) by print-shops for the apps they use in order to create successful print projects but without this help many of these users would have hard time with Adobe color management, as well.
  22. Please ensure two things: first that what you mean by "grayscale" definition for the subtitles has been done by using CMYK values (CMY parts zero and K part 100) and not the Affinity grayscale ramp or swatches, which are RGB based and produce four-color grays, and secondly, that when you export, you do not embed the document color profile (or if you do, that you use the same color profile in the viewer app). Otherwise the exported gray text parts will appear to have become four-color grays while in fact they are still using K definitions (however, they might become four-color grays in final rendering depending on how the document is processed and if unnecessary color conversions are done at this stage). There might be point in exporting using one of the PDF/X methods, e.g. PDF/X1a:2003, which ensures that all data is in CMYK format (and mere K definitions are retained), and rendering intents are included and colors shown correctly in viewer apps like Adobe Acrobat Pro.
  23. I found this: https://developer.mozilla.org/en-US/docs/Web/SVG/Namespaces_Crash_Course ...and specifically: So non-standard namespaces like "serif" should be declared first. In the code by OP the declaration part is not shown, and in the code example above by @Pšenda the namespace declaring part might be truncated but if the namespace is not declared, rendering this code: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 303 148" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;"> <g transform="matrix(1,0,0,1,-155.504,-83.4629)"> <g id="Rects1" serif:id="Rects1"> <rect x="155.504" y="116.954" width="71.07" height="84.264" style="fill:rgb(159,209,177);"/> <rect x="191.018" y="149.437" width="81.242" height="81.226" style="fill:rgb(249,238,121);"/> </g> </g> </svg> e.g. in Chrome or Firefox, causes this: ...so it is not just a question of assuming a robust parser. One cannot assume that custom namespaces can be used carelessly, just assuming that parser can handle (= ignore) what it does not recognize. Adding the name space declaration xmlns:serif="http://www.serif.com/" in the code above within the svg tag fixes the problem: So there is point in checking that the namespace declaration is included in the code created by Affinity, e.g., if using directly the code pasted on the Clipboard. As I tested this both with Clipboard and digital export, the declaration was there, and in this case this is a React issue. If the declaration is not there, this is an Affinity issue. UPDATE: If you use e.g. Designer simply to produce single objects in SVG code via Clipboard (or by extracting objects from an exported SVG file), you should make sure to manually add the Serif namespace declaration to avoid problems.
  24. It is not always as simple as in this demonstration. And you cannot do even a simple job with Word or LibreOffice Writer if you need to have it in CMYK or even K100, or if you need to add background with bleeds and have the job trimmed, include and precisely position and crop photographs, add vector graphics, etc. InDesign has a very handy data merge feature which I use frequently for e.g. conference graphics (large name tags with logos, country flags, etc.) and I cannot imagine creating these kinds of things in anything like Word. Why not have it in Publisher if it is in the competition (though nowadays in QXP only as an extension)...
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.