Jump to content
You must now use your email address to sign in [click for more info] ×

lacerto

Members
  • Posts

    5,729
  • Joined

Posts posted by lacerto

  1. 37 minutes ago, Hangman said:

    I think the issue is that Affinity apps don't support Global (OCG) layers on export so regardless, it is always going to be a manual process to merge Layers... I couldn't figure out any way to do this using the Command Line...

    Yes (except for one-page jobs where "globalness" is irrelevant). OCG layers as such are "supported" in a meaning that PDF layers get generated in the first place. They are also supported beyond Adobe functionality as it seems they can be at least 3 levels deep (I think most other apps, including ones by Adobe, create only 1-level deep PDF layer structures, and also flatten layer structures that go deeper than 1-level, when they open PDFs for editing (Affinity apps excepted). 

  2. I have never realized this pixel alignment thing in context of Publisher. I do get it when positioning vector objects on a raster canvas (typically in Photo), and I have occasionally experienced it when placing Photo documents within Photo documents, but not in these kinds of contexts, and cannot reproduce this behavior in context other than when needing to rasterize images on canvas (but then Publisher typically leaves blurred edges around the image boundaries no matter whether the image was perfectly pixel aligned or not). 

    I would check, in case the PPI of the placed image is clearly higher than the document DPI, that downsampling is not used at export time, and if it is, that the downsampling method is one that does not cause blurring. Or, if it is a question of an image like screenshot with low PPI placed in a higher resolution document (e.g., a 72ppi image placed in a 300dpi document), that the image has not been cropped with Vector Crop tool, since if this has been done, the low-res image that would look perfectly fine if it is let resized mechanically (by pixel duplication), would be upsampled by Affinity Publisher using Bilinear algorithm, which would result in a blurred image. If this is the case, simply crop the image using clipping method (clipping the image into a rectangle), rather than masking it, since masking (= effectively using the Vector Crop tool) will cause inadvertent upsampling of cropped raster content.

  3. I think that Affinity apps implicitly convert CMYK and non-sRGB RGB documents to sRGB using Relative Colorimetric conversion. I have not tested if Rendering Intent can be affected by using the setting under Preferences > Color, but at some earlier point when I tried this, the setting did not have effect on conversions made within an Affinity document (when converting from one profile to another).

    UPDATE: I now tested this, and the setting DOES have effect on these conversions.

  4. I now used Junicode in InDesign, and might have a little (but only little) better understanding on the way glyphs are listed in Stylistic Sets and Character Variables (both in InDesign and Affinity apps). They do get listed also in InDesign as a category (rather than just contextually as alternatives for selected glyphs), but this is not so obvious for anyone not well aware of internals of OpenType technology unless using sorts of super fonts as Junicode.

    It seems that InDesign lists alternatives for a selected glyph based on encoding (glyph names), as e.g. for Latin capital letter Eng it also lists Runic letters Ing and Ingwaz, so stylistically and otherwise totally unrelated glyphs. CorelDRAW does the same thing when using its OpenType contextual selector, as does VectorStyler. Perhaps this is what you mean by "construction" of aalt glyphs for glyph selection, whether they exist in OT for a selected glyph or not? 

    Anyway, when having Junicode active, InDesign does list up to 20 Stylistic Sets for the font, and, it seems, without showing the table names, all available Character Variable tables, as well (in order):

    The screen recorder I use on Windows unfortunately appears to disable tool tips so the glyph names (and cv codes) shown by InDesign are not displayed in recording, but it seems all tables from cv01 to cv98 get listed. There are also some other unnamed tables like rtlm which lists Runic letters.

    On the other hand, Photoshop 2024 (latest version) only shows three alternative glyphs for capital letter Eng (in Junicode), not the Runic ones, but then fails to show any if Alternates for Selection is selected. And it only shows three named Stylistic Sets for the whole font. So I cannot say that my confusion has remarkably diminished.

  5. 6 hours ago, kenmcd said:

    ID does not support cvNN at all (there is an add-on available which does).

    I am not sure what you mean. Even CS6 shows them in the Glyphs panel as Alternates for Selection, and the glyph info itself shows whether an alternative is coded as character variant (cv), or something else. But they are not listed uniformly in a separate control (nor are stylistic alternatives), unlike in Affinity apps.

    cv_id.jpg.e95e6ddc1fe30d14a145ece042f23c86.jpg

    6 hours ago, kenmcd said:

    Affinity only shows the actual OT feature Access All Alternates (aalt) if it actually exists in the font. Adopey apps construct this (whether it actually exists or not in OT) and that is what is displayed in the alternates pop-up. 

    I do not understand. Are you saying that these are constructed alternates?

    image.png.536e1173cfde5ab121ab1114f04bfe66.png

    The difference I was referring to was mainly related to listing of Stylistic Sets. E.g. CorelDRAW, Adobe apps and VectorStyler only list two Stylistic Sets for Groovy Script, while Affinity apps list total of 29. Access All Alternates are also listed differently, in CorelDRAW, Adobe apps and VectorStyler only forms that actually exist get listed, in Affinity apps total number of alternates gets listed for all glyph selections, whether any alternative forms exists or not (and whether irrelevant features are hidden or not).

    I am just confused, and probably have misunderstood something. 

  6. On 3/22/2024 at 5:38 PM, ShenaJ said:

    Takes a bit more thought, but happ to get it to work

    What a technologically interesting font! The way it works and makes its alternative glyphs available made me wonder whether there is some specific method (e.g., using a pen) to invoke different glyph versions, but based on the YouTube video created by the author of the font it seems that no, the text is basically supposed to be composed (or enhanced) letter by letter, and for this purpose Affinity Typography panel with dynamic Alternates controls suits acceptably well even if the size of the alternates remains pretty small.

    But as the Character panel has a button labelled as "Character Variants"...

    image.png.5f3047a44ea008c7daa0b15e223c6333.png

    ...I wonder if this is something that is intended to show alternatives for single characters in a separate window (and in bigger size), but just has not been implemented yet? (I could not find a way to make this feature working with any of the fonts that I tested.) Another thing that seems to need some improvement is the Typography panel itself, which cannot currently be resized (especially in width, to make more wide character selections fully visible), and using white text samples for stylistic sets in the Stylistic Sets list (in context of the Character panel).

    image.png.8ca95838308c7056f89a4a12d48e5d04.png

    This font made me also wonder whether certain typographic features like "Contextual Alternates" and "Stylistic Alternates" (and the combination of both), and even Stylistic Sets, are kinds of presets designed to be used with all the characters using the same font (instead of requiring character-wise selection of alternatives, which there can be over 20 for certain characters)? Based on my very superficial tests, in context of certain fonts it might be so, though the output might be a bit different when used with Adobe apps, and Affinity apps and CorelDRAW (which btw. could be an issue when opening IDML files that use advanced OpenType typographical settings). But with many fonts that I tested (including Adobe Pro designs), it was not so, so applying e.g. a specific stylistic set for entire text would produce absurd results (end forms used uncritically disregarding position of the character, etc.). Also, text might have multiple stylistic sets applied. But I began to wonder this because Adobe and Affinity apps show available stylistic sets quite differently, Adobe apps (including Photoshop 2024) and CorelDRAW showing all available stylistic variations only in context of glyph selection, while in context of e.g. Groovy Script only two stylistic sets made available in menu context, while Affinity apps show all stylistic sets available and appliable options in menu context.    

     

  7. 7 minutes ago, Alfred said:

    It really would be better if the app refused to allow an operation which is incompatible with the chosen file format. I haven’t checked whether a warning is triggered by an attempt to save a JPEG as CMYK when the existing file is RGB (or vice versa) but if not it should be!

    Yes, I agree. But I am not sure about the parallel case with a JPG file (when saving back keeps the CMYK format because it is technically possible). If saving back without confirming an overwrite is supported in the first place, what kinds of operations would be radical enough to require a user confirmation -- switching the color mode IS a big change so at least it is a good candidate; but there are limitless ways to completely change an existing image and it would be difficult to decide a reasonable trigger for a warning.

  8. You cannot technically save an opened .PNG image as a CMYK file (even if Affinity app will seemingly allow saving a CMYK .PNG file "back" with existing file name). When you close and reopen the file, it will still be in RGB color mode (but at least the colors are not messed up, as they used to be at some point). [So, after conversion, export the image to a file format that supports CMYK, like JPG or TIFF.]

  9. I noticed that the blending effect can vary a lot when exporting to CMYK and that graduality of the fill opacity set in Blend Options can come back:

    The document used above is RGB/8 and all color definitions are RGB based. The effect shown in the clip when exporting to CMYK would happen only when exporting to PDF, but not when exporting to CMYK JPG or TIFF. It is pretty much impossible to predict in what way the blend option fill opacity will differ from fill opacity set in the two alternative ways, so this is really just something experimental. But as the difference of effect is stated in documentation, the feature probably works "as designed".

  10. It seems that blend mode fill opacity does not actually work at all for certain blend modes (e.g. Vivid) and color values, e.g. in the clip below where a blue ellipse on top is blended with an underlying rectangle with linear gradient from R255 G0 B255 to white (so the objects are sharing the blue channel all the way). There is no gradual change at all, but decreasing the fill opacity from 100 towards zero has the same "blend effect" right from 99% to 0%. In different conditions blend mode fill behaves less radically different compared with identical objects with reduced color and layer opacity but as for the assumed gradualness of fill opacity, the functionality simply just seems to be lost (= opacity is just 100% on or 100% off).

     

     

  11. 2 hours ago, DJP said:

    When I change to one of the built-in styles, such as 'Body' or 'Bullet 1' (which are based on 'Base'), the text still shows as 100% black.  But if I open the style to edit it, I see CMYK sliders set to rich black (I guess . . . ), but these values are not applied when I check the box next to Text Fill. 

    This might imply that the document was initially created in RGB color mode, where text styles are based on RGB, and black text would be RGB 0, 0, 0. The CMYK conversion value of pure RGB black would be something like you mention, depending on the underlying CMYK color profile.

     

    Note that if you switch the document color mode from RGB to CMYK, the style definitions stay RGB based. This can be confusing but it is a kind of a forte of Affinity apps that they allow this. It is similar as in InDesign, where support for multiple color modes is more controlled and enhanced, and also well documented. 

  12. 10 hours ago, Old Bruce said:

    As Walt said "It may be a Magic Mouse thing" My experience with Macs (about 30 years worth) is that Apple has worked very hard to make bad mice. Their trackpad is really quite good. I would never buy a mouse made by Apple.

    I pretty much agree. Perhaps they had to try so hard to be a bit "innovative" to live up with the joke of suing Mickey Mouse (now partially PD) for a mouse (after losing the case against MS for windows)... As I myself have that mouse (but do not use it anymore), I remember to have found a utility that allows disabling the feature. Horizontal scrolling can be useful, though, and I have it in MX Anywhere 3 via Shift + mouse wheel, which works really well. 

  13. It is quite confusing. Check the video clip below to better understand how color controls in Affinity apps operate and how you can determine the actual color that an object has been assigned with:

    In a nutshell: the two ways to find out the actual color a text or native object (shape) has, is to use the Color panel and turn the lock off (on macOS, you might need to de and reselect an object to have the color values of a model made active updated), or using the color creation button when creating a swatch in a document palette within the Swatches panel (and having the list view turned on so that you can directly see to color component values). Note: Remember to switch back the lock in the Color panel to avoid inadvertent color mode conversions since if the lock is turned off, just switching the color model in the Color panel will result in conversion of color mode of a selected object. [EDIT: Note especially that using color pickers will NOT show the true underlying color model of an object that you use the color picker for, but the color value of that object when converted to the active color mode that the document is currently using (and that can be switched, without causing conversion of existing color values of text and shapes; values of pixel objects, however, would be auto-converted when switching the document color mode).]

    As for other controls, e.g. the Font Color rectangle on the context toolbar, or the Text Fill rectangle in the Edit Text Style dialog box, simply just switching the color model does NOT automatically convert the color model of underlying style, or selected object. But Publisher will "remember" the last model that was selected in these contexts so if you change to "CMYK" model, the next time you access the same controls, they would show CMYK models. Note that actually typing in color values or selecting a color when using a specific color model, would result in redefining a color value for a selected object, so always be careful when using color controls in Affinity apps. [EDIT: As for styles, you can also find the actual color definition in plain text, if you drill down deep enough and read the style definitions of the base style.]

    Note too, that the active document color mode in Publisher (or other Affinity apps) does not mean that colors that you define for objects (texts and shapes) would be automatically converted to the document color mode (which many other apps do); instead, they will be saved in meta data of each and every object you create or edit, so different objects within a document can well have definitions based on different color models, like RGB, HSL, Grayscale, CMYK, and Lab. 

    So, to recap: In most contexts, just switching the color model within a color selector, will NOT result in conversion of the underlying color definition for a selected object, but only actual color selection, or typing in a color value (even if the same as the object currently has), will. But in the Color panel, just switching the color model WILL, unless the small lock icon is turned on (and by default, when you create a new document, it will be turned on). 

     

     

  14. On 3/21/2024 at 1:35 AM, CT15 said:

    Thanks for this. I normally do so when using two vector objects. Just found it weird that it wouldn't export as is, but when only adding a black background, no white boxes appear on PDF export. Even with the layer using erase blend mode.

    Erase blend mode easily back fires when combined with adjustments (like inverting curves), and it basically always needs something against which to erase so if your purpose is to create cuts (see throughs) and place them on top of arbitrary backgrounds in other documents, this does not work. As mentioned, you need to create such shapes by using vectors. But if your design is self-contained and rasterization is not a problem, then Erase mode can be a great way to create the kinds of distressed textures your are having here.

  15. It seems the cause is the Erase blend mode applied on curves creating the text in left and right ribbon, and rough in the Underdog and Barbershop treatments. The former are easy to fix by merging the curves forming the text and subtracting them from the surrounding curve object, but the rough needs to be created in a different way (the underdog and barbershop "texts" and roughening objects should both be either curves or raster elements).

  16. 6 hours ago, David in Яuislip said:

    magick identify -verbose test.bmp

    Thanks, that is useful!

    have a yearly need for updating 4-bit dithered RLE compressed bitmaps using a custom palette, and Photoshop CS6 has a bug when saving back to 4-bit. Current version of PS has this bug fixed but I will stop subscribing sooner or later, and Magick could be a good replacement.

    Btw: I could not make +dither work for turning off dithering but 'magick clipboard: -define dither:diffusion-amount=0% -colors 16 bmp3:im_nodithering.bmp' can be used as a workaround. 

    UPDATE: Having played with ImageMagick for a few hours, my conclusion is to recommend GIMP as an alternative, if Photoshop is not available. It handles e.g. Floyd-Steinberg dithering especially with colormaps way better (much in Photoshop style) than ImageMagick, and if retaining of existing palette is important, GIMP is probably the best free tool available for the job. [But because command line tools typically have a pretty steep learning curve, it may well be that I have just failed to learn use the tool optimally.]

  17. 3 hours ago, walt.farrell said:

    Save is enabled for raster formats that you've Opened, and for PSD if you've Opened one and you have the "Save over PSD" option enabled in Settings. And for the Affinity file types, of course

    Yes, I know. Therefore (IMO) it should not be enabled for formats that cannot be directly saved. It is not directly obvious which formats can, so hitting Ctrl/Cmd+S and trusting that Save As will be opened, might result in inadvertent overwrite in those occasions a TIFF, PNG or JPG (or PSD, if enabled) has been opened (and can be saved back).

    [In other words: IMO "Save" should be available only for formats that CAN be saved back. So just for the native ones and those mentioned above, never for TGA, GIF, BMP, WEBP, or PSD (unless allowed) -- or any vector formats, either. IMO the extension of these formats should be removed right when a file of this format is opened, to make it clear that the file will be saved using a different extension/format, but this, of course, is not necessarily obvious on macOS or if "known" file extensions (made by default unknown by the OS) have been hidden.

  18. 50 minutes ago, David in Яuislip said:

    magick clipboard: -colors 4 bmp3:test2.bmp

    ImageMagick is an excellent free utility but why force colors to four instead of allowing the maximum of 16 (in a 4-bit image)? Whether the image is allowed to dither or not might also be worth a consideration (for some reason I could not turn off dithering with +dither command switch). Compression is yet another parameter that might need to be attended if retaining existing properties is important (especially after transferring image content via Clipboard).

×
×
  • Create New...

Important Information

Terms of Use | 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.