lacerto
-
Posts
5,768 -
Joined
Posts posted by lacerto
-
-
Emboldening and italicizing (done either via the shortcut Ctrl/Cmd+B or Ctrl/Cmd+I, or a toolbar button), is broken in Affinity apps anyway and only works in simple cases (like families that only have four styles). Even if the font has proper style linking defined, like Myriad Pro (a pretty complex style linking across 40 styles in the family -- the font is by Adobe so style linking is impeccable):
A typical issue is that emboldening and/or italicizing might work, but it is not a proper toggle because turning off bold or italics activates a different styling from what was the initially used. Or, that emboldening and/or italicizing fails in the first place and are linked to wrong fonts. Sometimes key shortcuts work correctly but the buttons do not.
Style linking does work properly e.g. in Adobe apps, CorelDRAW and Microsoft apps (and LibreOffice apps of which I have only checked Windows versions), also on macOS where such style linking is not that common.
But in Affinity apps, this is what happens, on either platform (the recording is on Windows):
As mentioned, sometimes keyboard shortcuts and styling buttons give different results in Affinity apps (but in case of Myriad Pro Light, the results are identical). This issue has been demonstrated years ago but I am not sure if it has been reported; if not considered "by design", it is probably one of the last ones in the list of issues to be fixed, especially if it is true that Affinity apps are "macs first", as has been suggested. Just for a reference: in Pages the Bold button also switches Light style to Bold (not Semibold as it should), but when toggled, the correct initial style (Light) is reverted. I am 100% sure that this is the way Apple thinks the "Bold" button or shortcut Cmd+B) should work (ignoring style linking which is likely to be considered a legacy Windows feature from the times Windows had inadequate methods for font enumeration in menus and presenting different styles under a common family name; traces of this can still be seen e.g. Microsoft Word, which does not even try to use common family names but nevertheless maps styling links correctly).
-
You can do quantization to exact number of colors using a trick that I have shown a couple of times on this forum (earlier video clips probably deleted because of Affinity forum max storage limit), using the Gradient Map, Posterize and Black and White adjustments (in this order) on underlying layers (projected against a solid background):
Note how Affinity apps create a document palette based on effect of adjustments even if part of the manipulated layers fall outside of the background (so that the image actually still has dozens of orange tones, quantized number being effective only within the boundaries of the background rectangle).
-
4 minutes ago, Gigatronix Pete said:
It is 2 x 3mtr x 3mtr wall images
The physical dimensions as such should not be a problem, but if the job has transparencies, exporting to EPS means that transparencies will be flattened and there might be large rasterized areas involved, which could potentially cause memory issues. But this is just guessing, and it is hard to tell if there is anything in the design that could be done otherwise to make EPS export work.
-
1 hour ago, Gigatronix Pete said:
When I asked them they said this came up when they tried to open the EPS files
Ok, thanks for the update. This is odd. Is it a very complex file, or is the size of the artboard very large? There is a chance that exporting using Level 2 PostcScript makes a difference. Could they open the PDF versions without issues?
-
Your customers might have expected specifically Illustrator EPS files which retain native Illustrator elements and full editability in Illustrator. Affinity apps cannot create such EPS files but only standard EPS files with some limitations (e.g. fonts are converted to outlines, and spot colors and overprint settings are not exported). Standard EPS files also do not retain layer structure of the document, and their editability is very limited. Illustrator should be able to open such files, though, so check what your customers mean when they say that they cannot open the files in Illustrator. Also, open the exported EPS files using your Affinity app to ensure that they are not corrupted.
Exporting using PDF format (or SVG, if it is a question about RGB mode documents) might work as alternative formats if EPS files simply just do not work. You could also try if exporting using PostScript level 2 works better (but it is unlikely that this could be the cause of the problem).
-
-
5 minutes ago, loukash said:
You can somewhat emulate it by turning antialiasing off and finetune using coverage map.
It is quite different. The coverage map kind of applies how (on what parts) antialiasing is turned off (or diminished). It typically works poorly with type. One of my posts above shows what the blend options based (partially) disabled antialiasing does. It is a really poor workaround with small point sizes.
-
10 hours ago, loukash said:
Interesting! I never realized that something like this even exists – possibly because I've rarely ever used a bitmap editor for typography work.
In small point sizes aliased text (earlier achieved with bitmap [system] fonts of different sizes) typically works much better than antialiased vector-based type rasterized real-time. When looked at certain distance, the human brain (appropriately limited eyesight) creates the best possible combination of accuracy and smoothening of edges. This has become less necessary in the event of high-res (4K) displays, but the feature is still quite useful in situations DPI is less than optimal.
-
7 hours ago, Medical Officer Bones said:
Just for testing: also works fine in PhotoLine when anti-aliasing is turned off.
In my experience non-antialiased rendering of text works identically in any app that supports the feature. I have tested so far Photoshop, GIMP, CorelPHOTO-PAINT (both Windows and macOS), and Acorn. All these apps also can fetch hinted versions of glyphs (e.g. TrueType hints for 2 and 5 for LiSu), but more generally: they do non-antialiased rendering identically for any fonts I have tested, whether hinted or not, whether TrueTypes or PostScript based outlines.
Affinity apps basically just turn on all antialiased pixels above certain threshold:
...and here is how it is done in Acorn (and PS, CorelPHOTO-PAINT and GIMP, and...):
-
5 hours ago, Discover Hawk said:
It's like this, after testing, GIMP's performance is also not good in this situation.
Do you mean that it is sluggish, or what? It seems that this is a question of app's support of TrueType hinting, and when I tested this with Photoshop (25.6.0) and GIMP (2.10.36), using LiSu, and FontLab 8.3 (using Monochrome hinting), the results are identical as for rendering.
-
Disregarding the font, it seems that there are app-related differences that are fundamental as for rendering of non-antialiased type. I initially (and naively) thought that turning off antialiasing in Blend Options would "simply" just revert to turning off resolution-dependent skeleton glyphs math. That is, that having "None" as an antialiasing method in apps like GIMP, Photoshop and any of the Affinity app trio would give identical rendering, when having the same document DPI.
That it is obviously NOT so, it is a worth of a more fundamental study or declaration!
-
1 hour ago, Discover Hawk said:
This is what it looks like in Affinity,when turning antialiasing off (same file)，It looks ugly and can no longer be read:
Yes, it is poor. Using Thresholding might give you something more closely to PS aliased text, but its readability is also much weaker compared to mathematically accurate glyph-determined rendering that can be achieved in PS (or GIMP).
-
I personally much prefer apps that directly let the user decide whether to use system (2 kinds) or app specific (4 kinds) antialiasing, or what was asked, no antialiasing at all
The last option, turning antialiasing off, luckily exists also in Affinity apps (Photo, and the whole trio, when exporting rasterized), and you can simulate the other options:
-
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).
-
1 hour ago, LukeBronsky said:
@lacerto Do you know any other way around it except the one mentioned earlier?
There are probably many PDF editors that can do this, including (possibly free) online versions. If you are on Windows, there is one that I can recommend, PDF-XChange, not free, but with a low-cost perpetual license.
-
On 3/24/2024 at 10:04 PM, LukeBronsky said:
the layers on multiple pages are not linked - meaning you'd have to select the visible layer for every page of the document separately.
Yes, this happens because Affinity apps do not support global layers. They are page specific, also when exporting PDF (OCG) layers.
-
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.
-
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.
-
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.
-
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.
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?
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.
-
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"...
...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).
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 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.
-
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.]
- Alfred and henryanthony
-
2
-
At least in v2.4 (of all three apps), you can also copy SVG code from VSCODE onto Clipboard, and either paste it as a rendered image on the canvas, or paste it in an already existing text frame as text. This used to be possible earlier only in macOS app versions.
PDF export from Publisher does not contain text information
in Affinity on Desktop Questions (macOS and Windows)
Posted
Because the output of the attached PDF was in PDF v1.6, my guess is that the PDF was exported with "PDF (Flattened)" preset. This method uses PDF v1.6 and does what it says on the tin, that is, "flattens" everything, meaning that it creates a single image of the whole spread. Perhaps there was a misunderstanding (fairly common in e.g. POD-context) of the term "transparency flattening", which only means that live transparencies should not be included in the PDF output. PDF 1.6, however, does specifically NOT do that, but just "flattens" everything to an image (but would enclose the whole spread in one transparency group using RGB blending mode, probably caused by outer F/X used in some picture frames in the design, so some extra confusion from there, too).
[Note that the industry also uses term flattening for things like layer removal = flattening everything to "paper" background without a transparency and flattening text = producing a file without embedded fonts but rather having the text content either in outlines or rasterized in high resolution, so the term "flattening" can indeed be confusing.]
If this is a collaboration article (e.g. something like "one self-contained press-ready device CMYK spread with all images and fonts embedded") to be included in a larger publication, the safest export method from Publisher would be using PDF/X-1a:2003 -- unless the complete magazine is created with Publisher, in which case it much depends on the final PDF press settings, which PDF version should be used in placed PDFs to avoid rasterization (e.g., if PDF 1.7 can be used in final PDF, any PDF version is compatible; if the final PDF needs to be in PDF/X-4, PDF/X-3 and PDF/X-4 can be used, but not anything else; if the final PDF needs to be in PDF/X-1a, any placed PDF is typically rasterized).
If the main publication is created with InDesign or QuarkXPress, it is basically free how the export from Publisher is made, as these apps can produce the kind of PDF needed in press without worries of "PDF compatibility" and inadvertent rasterization, which in Affinity Publisher context happens if mixing "incompatible" PDF versions in placed content.