Jump to content

Lagarto

Members
  • Content count

    599
  • Joined

  • Last visited

Posts posted by Lagarto


  1. I think that this is "by design". Affinity apps do not have a specific [Black] or [Registration Color] color swatches, as does InDesign, so the mere black (K) values will be converted to CMYK according to the specs of the color profile. InDesign actually behaves similarly if you create a separate K100 value (instead of using [Black]). What is more serious is that Affinity Publisher does NOT change the color values of user-defined color swatches, accordingly, resulting in break of all (non-spot) color assignments, including global.

    I would not use the "Convert" option unless it is absolutely necessary. Normally it shouldn't be. If the change of color profile is needed within the same color mode (.e.g, just using different CMYK profile), I'd use the "Assign" option. That does not change color values, but would still affect the way the RGB images are exported (e.g., this could be useful if you change from coated to uncoated, or vice versa, and just want it to affect the imported RGB values but not your text and internal vector graphics, or just want to assign the printer requested color profile). This kind of change should be done at this stage rather than in export settings (where CMYK values would be converted similarly if the document and target CMYK profiles are in conflict).

    You mention "Windows version only". I have currently no macOS version of any of the Affinity apps installed so I cannot check this, but I find this quite surprising. Could you rechecki and confirm this?


  2. On 11/2/2019 at 7:22 AM, mileslowe said:

    that x number of layers max number has been reached and it will not export the rest of the layers.

    Can you share information on the number of layers that actually were imported? Note that "layers" are "Layer" layers in Designer (as there each and every object is a layer in itself) -- it would be important to know if there are either kinds of exact restrictions (max number of objects / max number of "Layer" layers). I have noticed that if an opened .AI file has great many objects, there is a limit above which none are imported, but I have never received an error message related to this, so just erroneous behavior without warnings.


  3. 13 hours ago, softsound said:

    Actually it appears that pdf/x-1a:2003 works fine for IngramSpark checks!

    My experience has been similar, as both are pretty old standards. Automated checks may fail for trivial reasons, and if the upload is discarded, there is normally a way to hand over the job by other means. The standards were created to facilitate print pdf ceation, delivery and processing, and not to create obstacles where preflight tools or expensive third party libraries are needed to check that everything is "go".

    PDF/X-1a:2001 is PDF 1.3 based and PDF/X-1a:2003 also supports PDF 1.4 (which is the default for creating any non PDF/X-based press PDFs from within InDesign). PDF 1.3 is "idiot-proof" but very rare printers actually require PDF 1.3. I do not think that Affinity apps even support exporting to PDF using other than 1.4+ based versions, so if the printer really requires PDF/X-1a:2001, I guess there is no other option than picking up a printer that is more flexible.

    UPDATE: The major difference between PDF 1.3 and 1.4 is that the latter supports transparency. However, Affinity's PDF/X-1a:2003 does flatten all transparencies so it is "technically" PDF/X-1a:2001 compliant, so if it does not pass a check, the reason is (probably) trivial and the file itself should work without problems. 

    UPDATE2: For anyone interested, the PDF Preflight tool that comes with Adobe Acrobat Pro X, does not make a distinction between PDF/X-1a:2001 and PDF/X-1a:2003. I tested a couple of simple Affinity Publisher exported print PDFs created by using the default (unmodified) internal PDF/X-1a:2003 settings, containing overlapping transparent texts and graphic objects (both having a transparency setting) -- which at the export get flattened -- , and the files passed the PDF/X-1a compliance verifying routines of this Preflight app without any warnings. As Affinity routine also seems to flatten the flattens the transparencies, this export routine could be considered pretty failsafe. But it is naturally recommended to create the PDFs according to the specs instructed by the printer, if the requested method is available in Publisher.


  4. The recommended route depends much on complexity of the photo, but with Affinity tools, I cannot see other options than just tracing (manually drawing lines) over a bitmap to create closed areas, grouping each drawn area to be colored with the same color, and then, after checking that coloring works as wanted. manually entering the numbers pointing to the color legend. That would be a tedious task if you want the adjacent areas to align perfectly with each other.

    Automating this process and making it less tedious would require support for undithered indexed palettes, and a tracing feature, but Affinity apps unfortunately do not support either.

    See below how a photo would be converted to a color book by using Photoshop index feature that first reduces the number of colors in a photograph to 11 (an automatically calculated value) undithered colors, which then have been traced to vector art so that each of the colored area forms a group of its own (using e.g. Illustrator or CorelDRAW):

    coloringbook3.jpg.cab6a5e53d11ffb86e4fd3bcbba34b00.jpg

     

    coloringbook2.jpg.28f72b2ce86f46a116c625b87d104da2.jpg

    Over this kind of an area-colored vector graphics it would then be easy to add numbers that refer to each of the 11 colors in the image. Each colored area is outlned with a 0,25 pt hairline and perfecly aligned with neighboring color areas so it would be easy to separate the areas also with different gray shades.

    coloringbook.jpg.30b62c45108f0c95d2814445746abecc.jpg

    With Affinity apps, you could try if posterizing the original photo helps you give a simplified image to be used as a template for manually drawing different color areas on top of the image. If you do not need to test the coloring (and accordingly having closed shapes that can be filled), you can avoid the most tedious part or the process (making adjacent areas to align with each other), and just draw the outlines and then add coloring numbers.

    UPDATE: I tested this now with GIMP and Inkscape. You can do undithered color reduction and tracing with these two free tools, as well. You could then save the resulting vector image as an .SVG file and place it in Affinity Designer or Publisher, see the different colors as separate layers and finish it up as you wish, either making it a coloring book with numbered legends, or recoloring it, including it as in image as part of a larger publication etc.


  5. 3 minutes ago, walt.farrell said:

    My initial issue was also with a file created in the retail version, but my recreations were with files created in 1.8.0.499.

    Ok, thanks. I opened the affected file (original version) in the release version and do not experience any issues with editing the style there so it does not appear that there is anything special with the style. I wonder if there is any means to check whether a style was initially a table-based paragraph style?


  6. The updated drop caps feature with support for user-specified number of characters to extend the effect, does not operate ideally:

    drop_cap.jpg.c279ae9054eb4a86ceea52ee46819806.jpg

    There are multiple issues:

    1) The text following the last dropped cap is awkwardly positioned, as if using kerning tables, yet this text has autokerning turned off (0% kerning). What is worse, this cannot be properly corrected even with manual kerning, and it is not possible even to add space characters before the "h" character (they have not effect). This error only happens with letters like A, T, etc. which have kerning pair definitions, but not with letters like N, M or L.

    2) If the first dropped cap is a quotation mark, it will not be automatically changed according to the paragraph's typography language. See the difference to the next paragraph where correct quotation mark is automatically used.

    On the other hand, see the next paragraph after the drop cap: here autokerning is on, yet the letter "h" is not kerned under "T", simimlarly as it is in context of drop cap, where autokerning is turned off!

    UPDATE:

    3) The third bug in the feature is that if there are more than 1 drop cap letters, manual kerning that is performed does not affect the space between the dropped cap and the text following it, but the spacing between the previous two dropped caps.

    4) The fourth bug is that manual kerning between the last drop cap and text following (even when only 1 letter is dropped), does no longer adjust spacing of the successive text lines that are affected by the drop cap feature (e.g. 2 or 3 lines), but ONLY the first line (in release version this works correctly).

    The whole feature is now more or less unuseable.

     

     

    dropcap.afpub


  7. I experience crash when trying to edit any table related style (the style does not need to be related to table of contents).

    UDPATE: I am not sure whether the style in question was initially based on table style (e.g. Table Body, etc.), but now that I tested this with a new document, table styles can be edited without the app being crashed (so the error is experienced with a document that was initially created with the release version).

    Also, in the document where the crash always happens, I can edit all other styles (both paragraph and character styles), but not this one style, which I think was initially names Table Body. The style is used in table that is located on the master page and then applied on regular pages so that the table is copied on these pages. The table on the master page does not itself have any text but the table has this style associated to it so that when accessed from regular pages, the correct paragraph style is automatically used.


  8. Assign a color to an object (e.g. a circle) using e.g. Swatches panel.

    Double click the Fill color well of the Swatches panel to open Choose Color panel.

    The app does not response and completely freezes. In Task Manager the app, however, is not marked to be ("not responding"), but that is exactly how it seems to behave, and it must be forced to be closed.


  9. I have reported this a couple of times earlier but could not find my old posts.

    The wrapping feature has improved but I think there is still error in "Ignore Text Wrapping" feature (Beta 1.8.0.499 and current release version).

    As far as I have understood correctly, text wrapping should happen using the following logic (imitating behavior of InDesign):

    1) If graphic object has been set to wrap, it always wraps text around it, no matter what is the z-order of the object in relation to the text frame being wrapped. It wraps text even if the object is hidden (as in InDesign). (Orange ellipse wraps text in the green text frame.)

    2) If two text frames overlap but only one of them has text wrapping set, the text frame will wrap text in the frame that does not have text  wrapping set, disregarding the z-order of the text frames. (Text in green frame is wrapped by the orange text frame.) 

    3) If two text frames both have text wrapping set, the object that is higher in z-order will wrap text in the frame that is lower is z-order. (Blue text frame wraps text in the orange text frame.)

    4) If text frame has "Ignore Text Wrapping" property turned off, text in that text frame should not wrap. (Text in the yellow text frame.) If the InDesign behavior is mimicked, the setting should not affect in any way to the text frame's own wrapping properties (i.e., the way the text frame itself wraps text in other text frames). As it has been implemented now, the setting does change the text frame's own wrapping properties, which does not make sense, at all. 

    The question is, why does the yellow text frame below (which has text wrapping set on) wrap text in the orange text frame? The yellow text frame is lower in z-order than the orange text frame, and both text frames have text wrapping turned on, so the text in the orange frame that is higher in z-order, should not be wrapped by the yellow text frame. If "Ignore Text Wrapping" is turned off from the yellow frame, the yellow text frame (correctly) no longer wraps the text in the orange text frame (but instead the orange text frame now wraps the text in yellow text frame). 

    Attached is a Publisher file (note: saved in latest Beta version) so it is easy to test the behavior by toggling the "Ignore Text Wrapping" setting of the yellow text frame.

     

    wrapping_beta.jpg.a085d613efe0cc8c6a07f0b1212974a8.jpg

    wrapping_beta.afpub


  10. It is probably quicker to just re-create the squares, as instructed by @firstdefence.

    But if you want to work with the existing objects, you might want to use the Transform panel to do the job.

    Unfortunately the Transform panel's basic calculator capabilities do not support conversion of units in transformations, so if you want to add exactly 6 pts between the objects, you'd first need to change the document units to points. You can do this by clicking File > Document Setup.

    Then you would select three rightmost columns of your squares and enter +6 in the X box of the Transform panel after whatever value you currently have there, and Designer will add 6 pts to the current value. You would repeat this by selecting two rightmost columns, and then one. Then you'd repeat this for rows by adding +6 to the values in the Y box. (As far as I know there is no Repeat command so you need to type +6 for each transformation.)

    (Note that you CAN use the boxes of the Transform palette to enter values in different units, e.g. while you have the "points" as the document unit, you can select an object and enter 5mm as its width, and it will change the width of the selected object and convert the width to point values. But you cannot do adding and substraction by mixing the units.)

    Yet another way to do this would be using the object distribution feature of the Alignment panel, but as you only have a 4 x 4 matrix it is  more simple to just use area selection and move columns and rows.

     


  11. On 8/6/2018 at 4:35 PM, Fixx said:

    Well, either there is error in math or bigger 1-bit file just happen to compress better than downsampled one.

    Here are some figures for file sizes when saving the same image in different bit depths, compressed and non-compressed:

    filesizes.jpg.93f042b80ec0fa8707e1ff55dd99b3f0.jpg

    Note however that the bitmap image has 1200dpi, which it normally also needs to have, while the grayscale and RGB versions have 300dpi. The content for all files was same, random line strokes in black.

    These are lossless compressions for all file types (LZW for 8 and 24 bit and ZIP for 1-bit). You can use grayscale images for colorizing, too, but 1 bit images have some uses that other image types do not have. But there is necessarily no point in using them just for saving disk space.

     

     


  12. 4 hours ago, DegasBrush said:

    It works I tell ya I'm very sure it works! Screen Printers/T-Shirt guys you could specify pantone colors for seps and have that work for screen.

    Threshold effect itself is nice but I do not seem to be able to use it e.g. for screen printing via Color overlay, which just converts any Pantone color to CMYK. But I can do this by just giving the image a Pantone fill color. However a grayscale bitmap can only be used for overprinting. A true 1-bit bitmap can also be used to knock out. Unfortunately Affinity apps seem to convert 1-bit images to RGB (which in turn can of course be used as a grayscale image).

    There is definitely use for monochrome bitmaps in graphic design and it is a pity there is no support for this. 


  13. I think that the following three images show what is the key problem with unsmooth gradients:

    a) Original image saved as PNG24 bit (using background no. 5 shown above):

    faberge_transparencygradient.thumb.png.94364dc8d1c64f994c5cc8c182e2c547.png

    b) Midtones brightened from the PNG version (image above):

    faberge_transparencygradient_png_brightened.thumb.png.bf0acfd552230c52e8f4730c4512d841.png

    c) Midtones brightened from a JPG version (using 85% quality setting):

    faberge_transparencygradient_jpg_brightened.thumb.png.c6444fbc6e5f094592e1d22946e14e46.png

    Here is an example where the gradience is created from a much brighter start color, end color still being RGB 0,0,0. Both ends use transparency, start node at 50% opacity and end node at 0% opacity. In addition, the layer itself has 54% opacity, and the Faberge egg has a shadow effect applied with transparency used in the shadow (just to show that use of multiple transparency settings in an image does not itself deteriorate the image quality):

     

    faberge_transparentgradient_extreme.thumb.png.e791d9fee5503820830b401ddf1d026d.png

    Here is the manipulated image showing the gradient shade distribution:

    faberge_transparentgradient_extreme_brightened.thumb.png.05cae46200d92028e4a71faca184f060.png

    I think that these images show that banding is much a problem that is caused by using end colors that result in uncontrolled color shifts, and using JPG compression. It should be safe to create a gradient between two RGB colors AND use transparency in either or both ends, as long as attention is paid to the export format and color shifts. Keeping the other end as neutral (equal RGB values) is easiest way to avoid uncontrollable color shifts. Adding intermediate routing colors might also work in situations where this is not possible.

    Photoshop's "Smooth" and "Dithered" settings probably help in situations which are challenging (e.g. creating a gradience across the color circle) and where banding is likely to occur, but as Affinity Photo does not seem to have these kinds of controls, keeping the gradients simple (e.g., fading out to a neutral color), and saving as PNG24, should guarantee smooth results.

     


  14. 5 hours ago, MickH74 said:

    Another thing I have to watch is the file size. I would like to stay in the 300 KB range for a 4k-resolution jpeg. Using BMP is 3 MB or more and therefore no option.

    That's a tough challenge. I am not sure if there are effective compression techniques for 16-bit images; in context of textures 5:6:5 bit depth and some compression methods exist in APIs like DirectX but I do not think there are any generic apps that directly read and write this kind of stuff. Getting under 300K while keeping high quality would be difficult: very low-quality 24-bit jpg compression would typically use more than 400KB for saving a 4K file. 


  15. Ok.

    Do you experience the problems only with this specific point in the leaflet, or on multiple pages?

    If only on this page, I'd pay attention to the icons you have on the lower right part of the object. If they have image adjustments (e.g. Brightness/Contrast, or similar) placed above, they'd also affect the underlying dark blue page layer where you have the gradient applied, unless they have been masked, and would force the whole page to be rasterized when exporting to PDF. (You would limit an adjustment to apply only the object immediately below it by dragging the adjustment layer into the object's layer, or by right clicking the adjustment layer and choosing "Mask to Below" from the context menu that is shown.)


  16. 14 minutes ago, hikerbikerwriter said:

    Problems seems to still persist in 1.7.3

    On Windows version of Photo there does not appear to be problems. Projects created using the 300dpi setting will also be exported with this nominal DPI value at least when using JPG or TIFF format. Images resized with specified DPI value or marked (but not resized) to be using the specified nominal DPI value also export using the same nominal DPI value.


  17. 7 hours ago, MickH74 said:

    In Affinity Photo I would like to reduce the amount of colors in a picture to 16bit total (e.g. 5:6:5 bits per channel) and cannot find out how to do it.

    I do not think that it is possible in Affinity Photo, it has pretty poor support for anything other than 24-bit+ images. Photoshop supports these, possitbly also GIMP.

    EDIT: As @walt.farrell noted, there only seems to be limited support for <24-bit images (8-bit paletted under PNG). I checked GIMP, and it supports 5:6:5 16-bit images, under BMP file format, similarly as Photoshop, also when saving.


  18. Nelly, do the screenshots in your original post represent the actual work where you experience the problem?

    I could see banding effect in the PDF screenshot only when the highlights were cut down from 255 to around 150 and when the blue was already quite light. The steps of the gradient however show pretty uneven so I'd like to check if you have applied multiple effects on the layers where you also have the gradient? (You mentioned that you do not get any gradient if you do not rasterize, and this suggests that you might have other effects and at least adjustments applied on the layer; use of adjustments most often results in need to force rasterization.)

    I do not think that these would show in the printed product, though, but it would be good to find the cause for the unevenness, anyway.

    Have you tried to print the PDF on a local printer, and if so, can you see banding there, too?


  19. 12 hours ago, thomaso said:

    Lagarto, I guess the banding is too little to become obvious in the small + lowres histogram.

    Yes, but what I am wondering is that why JPG does NOT show banding while the PDF does. I cannot see any remarkable difference between the two screenshots. It would be good to have the actual PDF. I do not think that it is a display issue as the PDFs containing gray scale ramps from K0 to K255 and K0 to rich black did not show banded when viewed on OP's computer. Beats me...

    UPDATE: More specifically: when OP opens the gradients.afpub and exports the PDFs from it, they get banded output, but when they open the PDFs exported by me from the exactly same publication, they do not see banding. So it seems to be related to PDF export settings, but I cannot see how (which settings could cause such effect; rasterizing at 400dpi certainly not, but as mentioned, gradients are not produced at all, if the PDF is not rasterized). Odd...

×

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.