Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

About Lagarto

  • Rank
    Dedicated User

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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 translated 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...
  3. Holding down the Shift performs horizontal flip WHILE you in the same process have first flipped vertically (by dragging over).
  4. 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.
  5. 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.
  6. 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)
  7. 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.)
  8. 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.
  9. That's it! I searched if from Photo! But found out the way to get this information there, as well, so worth an effort!
  10. 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):
  11. 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.
  12. 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.
  13. 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?
  14. 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!!!
  15. 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.
  • 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.