lacerto
-
Posts
5,640 -
Joined
Posts posted by lacerto
-
-
5 hours ago, MikeTO said:
we have another two years to go.
So people who are running Intel macs (purchased e.g. as late as in 2021) would now have only about two years left until they lose support for running their computers and Intel based apps using most recent OS versions? Is there an official deadline? Wouldn't it most probably also mean that Intel based versions would not even be updated as they would need to be made separately available, and possibly also separately distributed as I would not be surprised if Apple Store requires Silicon support anyway?
There is also another consideration for those running M-based Silicon macs, as there are still many apps and especially add-ins and plug-ins that are Intel-only, and for which there is a risk that M-based version will never be developed. Stopping Intel-based support then means that those depending on these components need to repurchase them (unless provided for free by their manufacturers) or just cannot upgrade their OS versions because they could no longer run their apps using Rosetta.
It would be more appropriate to drop M-binaries than ever drop Intel-binaries, but neither thing is likely to happen (that is, getting Intel-only or always fat binaries). There is also a consideration of being able to run specific version of software sold based on perpetual license and limited download availability so that M-binary would be automatically available also when the user upgrades their computer to a Silicon based mac.
But I guess there is nothing new here. Selling devices is Apple's business -- including selling overpriced storage space. As for desktops, you need to keep on purchasing again not only at the crucial points where the processor architecture changes (Motorola => RISC => Intel 32 => Intel 64 => Apple Silicon) but a couple of times in between, too, because of limited OS and repair/service life-cycles.
-
Here are more comprehensive test files attached, and some notes on results after performing Boolean operations:
a) On Windows v1 (just as a reference):
- Red color indicates shapes that were left invisible after operation (not really an issue)
- The two elements Boolean operated on each artboard are from top to bottom: frame text + rectangle, art text + rectangle, frame text converted to curves and merged + rectangle converted to curve, and art text converted to a curves and merged + rectangle converted to a curve
- Subtract simple fails when performed on frame and art text, but works if text is first converted to curves and merged; subtract compound works fine
- Intersect simple fails when performed on text (all objects lost)
- Xor simple has issues
- Divide simple has issues when performed on text objects, works fine if text objects are converted to curves and merged; Divide compound fails to divide any objects
b) On Windows v2:
- Subtract simple still fails on operations involving frame text, or former frame text converted to curves and merged
- Xor has issues with frame text and former frame text converted to curves and merged
- Divide works fine only with art text converted to curves and merged
c) On macOS v2, when opening a file where text objects have been converted to.curves and merged on Windows:
- There are issues in Subtract, Xor and Divide when operating with frame text converted to curves and merged
- Divide simple fails with text objects
d) On macOS v2, when text objects have been converted to curves and merged on mac:
- There are still issues with divide simple when operating with text objects. Divide compound works fine.
What is strange is that the results are clearly dependent on the font that is used. The font in this test file was Arial. The differences between Windows and macOS might be dependent already on different versions of Arial these OSs have (the Windows version is much more complex and has e.g. OpenType fractions). Just using Arial Bold instead of Regular gives different results and gives similar or identical results on Windows (v2), compared to macOS:
In light of this, there is hope that this could be just a minor glitch, more related to specific feature in the font than the actual glyph shapes. If so, then it seems that the major issues that are left with Boolean operations are related to Divide simple involving text objects (on both platforms).
I might have done mistakes, so here are the test files I used:
boolean_regular_v02_before_from_win.afdesign (created on Windows and having versions of texts converted to curves and merged on Windows)
boolean_regular_v02_before.afdesign (having versions of text objects converted to curves and merged on mac, so using diffrent version of Arial)
-
34 minutes ago, ,,, said:
crucially different about the output of the text-to-curves code in the macOS apps versus Windows apps
Yes, something like this. I have noticed that converting text to curves and then merging the curve elements to a "Curves" object sometimes gives similar (correct) results as operating directly with text objects in macOS versions. But then oddly the operations might fail (on Windows at least) when having former text objects converted to curves and any simple shape object involved in the operation.
Below is a simple v1 and v2 example (that is similar as has been used in another post on the forum related to subtract issues) that can be used to demonstrate and test the Boolean issues. V1 files seem to operate ok (in v1 apps) if the Boolean subtract (and other operations, too) is done non-destructively (as a compound operation) but v2 gives yet additional buggy results even when using compound versions.
These files seem to be useful in testing other Boolean operations, as well, and most operations seem to be broken in v2 (Windows). In v1 having objects converted to "Curves" objects and then applying compound operation seems to work best. I have not tested these on macOS, but based on superficial tests with other similar files, Boolean operations now seem to work well (or at least much better) on macOS (also better than in v1 version of macOS).
-
Subtract as a compound operation to get it non-destructive. Erase always rasterizes on export.
-
You can also use the Resource Manager to select in one go all child images of selected picture frames and then delete the images, as shown in the clip below:
Note that picture frames do not need to be expanded, I only expand them here to show that "Locate in document" function basically switches current selection of picture frames (made e.g. with the mouse) to selection of images within picture frames.
-
I am not sure if I understood correctly, but if you select images within picture frames from within the Layers panel, you can unpopulate the parent picture frames simply by pressing the Del key (or choosing Delete from the context menu of the Layers panel). If you only have images within picture frames, you could first select all images in the document using Select > Select Object > Images and pressing the Del key to unpopulate all picture frames in the document.
- Mr. Doodlezz and MikeTO
-
2
-
5 minutes ago, ,,, said:
Designer 2 is OK and the same as v1 - it does not resize physical dimensions when changing DPI of a document with physical document units.
Ok, thanks, did not check but wrongly just assumed.
-
Just use some negative tracking (or kern character pairs that are problematic):
-
Hello @Josh9856, and welcome to the forums.
This is a common issue in graphic design apps and related to antialiasing. Some apps can deal with the issue in context of export by automatically overlapping inner and outer parts of these kinds of objects so that the gap is covered. Affinity apps unfortunately cannot do this so to avoid this, some manual work is required. Most often these issues would not show on printed design.
-
4 minutes ago, R C-R said:
So are we all in agreement that this is a bug in V2?
Who knows if this is a regression or an intended change not just been implemented in full? IMO Publisher and Designer kinds of apps should behave differently than fundamentally raster-based apps like Photo, but Serif clearly thinks differently.
-
Frustratingly, this continues to be an issue also in 2.0.4 Windows versions (I have not been able to reproduce these kinds of problems with macOS versions, not with 2.03, nor with 2.0.4). It would be interesting to learn why Windows versions keep on having problems with basic Boolean operations? V2 apps obviously use different code than v 1 apps, but is this a library issue or something related to proprietary code not just yet being "in synch" between the OS versions?
-
3 hours ago, MikeTO said:
I could be wrong, but I think that's all that the DPI field does and it really isn't important
IMO the primary role that DPI document setting in Publisher (and Designer) had in 1.x versions of Affinity apps was setting the resolution for objects that will be rasterized on canvas (similarly as the "Raster effects" DPI setting in Illustrator). The setting would also determine the default for resolution to be used when needing to rasterize objects when exporting (this can be overridden at export time e.g. in context of PDF export). IMO v2 apps (Publisher and Designer) behave incorrectly when resizing physical dimensions of the document when document DPI is changed. This did not happen with v.1 versions (even when the document unit was px), and I cannot see why this has changed. Personally I see this as an indication of fundamental problems in trying to keep alive the idea of one global workspace and document object model. This seems to be an eternal source of confusion both for developers and users alike.
-
18 hours ago, v_kyr said:
Not sure why I would need nowadays to explicitely vectorize QR code bitmaps
I agree, especially when having K-only button available in CMYK mode. Rectangle shapes stay non-antialiased on export no matter how resized, and even downsampling issues [or issues related to upscaling of an antialiased rounded shape like one below] can be avoided should it be needed to avoid blurred (antialiased) edges:
monochrome_simulation_v01.afpub
19 hours ago, v_kyr said:Even a good overall finding
Yes, well done, even if I have not so far myself found much use for the feature, perhaps for some effects:
Finally true vector brushes 😆 This one is pretty high on my long list of convoluted work arounds: Raster based "Vector brushes" accessed via Designer Persona, rasterized and vectorised in Publisher...
19 hours ago, loukash said:I consider it the best QR code vectorizer from all that I have used so far
A roundtrip via Photoshop's Create workpath on the Paths panel with customizable Tolerance settings (below 0.5, 2 and 6px) is not bad, either, and would allow some interesting QRCodes:
-
Works on my Windows 11 Pro and Affinity apps v1 and v2 (including Designer), similarly as when using e.g. VectorStyler. The numbers must of course be typed by using the numeric keypad, but this does not seem to be the issue since this works for OP with other apps. NumPad + 7 works, too (though I do not know if this is somehow OS specific).
-
You can use Excel sheet as data source but need to use TEXT() function to format data as text (note below that formatting notation is regional, so below the arguments are separated using a semicolon, the decimal is given with a comma and hour with a "t" (for "tunti", Finnish for hour)). English notation would be TEXT(A2, "h:mm:ss.000").
TIME() function would return rounded seconds, but e.g. NOW() returns an unrounded value. If exact values are wanted to be returned with TIME(), you would enter something like =TIME(0;12;32)+0,24/24/60/60., or when using English regional settings, =TIME(0,12,32)+0.24/24/24/60)
-
31 minutes ago, Ldina said:
Thanks again. That worked with my installed versions of Myriad Pro and Minion Pro
You're welcome!
Yes, any fonts that have OpenType fractions can be used with RegEx (or even without RegEx, using find+replace multiple times for different fraction scenarios) and using character formatting to apply fraction formatting (optionally made to character style).
Having additionally the context-sensitive trigger, as in e.g. Helvetica Now and Meta would allow applying formatting selectively (only in selected range or columns), and also in situations where RegEx is not available (e.g. if Publisher is not installed, or when working in apps that do not support RegEx, Find and Replace, or applying formats automatically on found instances; e.g. Designer alone would not support these operations, but still does support OpenType features). As far as I know fonts like Minion Pro, Myriad Pro and Arial (the last mentioned it seems that only on Windows), or Helvetica species other than Helvetica Now, do not support contextual OpenType fractions so fraction formatting would be applied also on the integer part if it is selected.
Needing to perform find and replace selectively (confirming found instances one by one) would make formatting quite ineffective so there might be point in getting a font that has fraction formatting as a contextual feature. As long as Affinity Publisher does not allow limiting the search to a specific or selected range, such font feature would be very useful.
The clip below demonstrates a situation where fraction formatting cannot be applied globally (because that would also change "fraction" in dates and font/leading markings), and where formatting is then applied selectively (column-wise) first to Minion Pro (does not work because integer part is formatted as well), and then on two fonts that support contextual fractions: Helvetica Now, and Meta Serif Pro.
-
This illustrates a situation that you might have:
a) Internal macOS version (part of TrueType collection):
b) Legacy Type 1 font, this one is from Adobe FontFolio 8 (which still can be installed on most recent macOS):
If I try to install this font using Font Book, it warns about a duplicate being in process of installation. As you can see both fonts use identical family name and style group with identical sub style. Many apps only read this information and accordingly would get confused font menus when enumerating available fonts. Adobe apps might have been able to handle these conflicts without problems because they read those additional names to identify and group the fonts correctly. But as this is a Type 1 font, modern Adobe apps no longer support it, and Affinity apps are helpless in differentiating these fonts.
The easiest method would be simply disabling the conflicting styles of the non-Apple version using FontBook. It would be possible to convert the Type1 versions and use non-conflicting names, but this would be a pretty big job (and besides, I assume that against the original license).
As Type 1 fonts are deprecated and more and more apps (and e.g mobile OSs) stop supporting them, it might be a good idea to get a new version of Helvetica Neue. Unless you want to have exactly the same design, I would recommend getting Helvetica Now from Monotype, as it is a superb font with lots of fine features. The MyFonts version is from Linotype and is basically an up-to-date OpenType version of the old Type1 font, but the package you referred only contains 16 styles while the original FontFolio 8 or 9 version contains 51 styles so there is a good chance that you will not get full support for opening all your old documents with the replaced versions, despite of identical design. In any case you would need to map the "missing" fonts of the old documents with old versions of Helvetica Neue to the new fonts with slightly different names.
EDIT: The Apple built-in OpenType TrueType flavor contains 14 styles. It you do not need all styles of your current non-Apple version of Helvetica Neue, just using the Apple versions (instead of purchasing a new Linotype package only containing 2 styles more) would probably be the most practical solution.
-
1 hour ago, Tony Pritchard said:
Helvetica Now is a reasonable suggestion but is quite expensive now that i am retired.
You can PM me to tell some details of this other font. Depending on a bit on details, it might be an easy task to prepare you a version that works fine on you current system, without causing conflicts with the internal macOS version. R/I/B/BI refers to Windows kind of four-style menu names which need to be consistently created to make super families like Helvetica Neue work. I think that Affinity apps and apps generally on macOS basically ignore this system and have other means that help grouping fonts. But name conflicts occur all the same, but for other reasons than confusion of four-style menu names. As I have the macOS versions installed, I could have a peek on your font and see what it takes to make a fix.
-
I think that it is worth investing in a modern OpenType like Helvetica Now, which comes with contextual fractions, and also some intellect as for excluding certain specific glyphs from ones that autotrigger inserting OpenType fraction formatting. This font family has also multiple styles so it works well whenever grotesque type is needed. There are probably serif-style fonts available allowing similar functionality but e.g. Minion Pro [at least the version I have] would also apply integer figures separated by zero-width space or non-breaking dash with fraction formatting, so it could not be applied en masse, similarly as on the clip below, but would require use of the kind of RegEx formatting shown in the video.
Anyway, if there is need to separate an integer figure from the fraction part, this font would allow using e.g. zero-width space or non-breaking dash [or another similar dash] as a separator, and both could be entered while typing by making these glyphs available with a keyboard shortcut. So when using this method, all fractions can be autoformatted both when applying OpenType fraction formatting afterwards (e.g. to whole table), and while typing. If necessary, existing regular dashes or spaces could be find-replaced with versions that will not auto-format to fractions.
Note that you should disable the auto-correction feature of the Preferences, that automatically replaces entries like 1/2 or 1/4 with fractional codepoints. OpenType fractions are a completely separate thing so this automatic feature should be disabled when using them.
I am not sure if Google fonts nowadays comes with anything as smart as Helvetica Now -- if anyone knows, please inform!
UPDATE: Meta Serif Pro would be an example of a serif font that has similar OT fraction feature as Helvetica Now. Probably many other FF fonts has, as well (e.g. Signa Serif and Signa Slab Serif do), of all versions. Helvetica Now supports both proportional and tabular figures (including fractions), all Meta fonts support additionally OldStyle and Lining versions. Meta fonts are included in Adobe Fonts.
-
Yes, the both Helvetica Neue versions on your computer seem to have same or close to same family names (perhaps a space character is not enough to separate the names, unless the app can make a difference when enumerating the fonts).
Font editors typically use the FamilyName as a base, and then other parameters to build several other names to create a unique set of font names to avoid name conflicts. Since e.g. PostScript name seems to be built based on Family name (spaces removed and style name appended by other parameters), it may be that at least certain fonts that have close to identical family names, end up having fully identical secondary names (like PostScript name).
If an app enumerates fonts based e.g. on PostScript body (the first part of the name), name conflicts would happen and all kinds of issues related to this problem. I do not think that it is possible to resolve the issue unless the family name of one of the conflicting font is changed and sub names thereafter rebuilt. As mentioned, the problem is often app-specific, depending on whether an app uses multiple name fields to deduce how individual fonts should be grouped and identified.
If name editing is not an option, you could try if just removing the exactly conflicting fonts from the non-Apple family would make it possible to use all sub styles of these fonts, even if from mixed families. The Font Book is probably good enough tool to do this task, as it allows just deactivating conflicting fonts without needing to uninstall them.
-
1 hour ago, nolamike said:
I think @lacerto you were copying as well in your example.
Yes, I was. I thought this possibility, too, and therefore tried again by placing one by one (without copying), but still could not have the pages saved. But as I did this AFTER I had initially already placed them by copying, it is possible that having initially used the copy method still had some effect on the issue. Nevertheless, I think that whenever I have used this feature before, I have always used a copy and then assigned the page, and I have not previously experienced this error (that is, in 1.x versions).
-
2 hours ago, Tony Pritchard said:
I'm not sure there is any way around this. Am I wrong?
What is the source of the non-Apple version? Adobe has the family name as Helvetica Neue LT Std (at least the OpenType PS flavor) so it differs from the Apple version (which is TrueType).
I have these two installed on the same system and they do not conflict (not within Affinity apps, either, and Font Book does not complain about duplicates):
One potential method to fix this would be using a font editor and rename the family of the non-Apple Helvetica Neue to something else. It is of course a large family so maybe quite a nuisance, and would or course require a specific tool.
-
1 hour ago, laurent32 said:
I'd like to have your advice, since it's vector graphics, why not consider saving files in SVG ?
SVG sizes aren't they the smallest ?
They are not necessarily smaller, but might be. It depends on details. But if the graphics is likely to be zoomed in, I would definitely use SVG and keep it as vectors, unless the size is an issue.
UPDATE: E.g., in this case, the size of the SVG 1.1 file would be 1,071 bytes and would certainly be the best choice:
-
1 hour ago, R C-R said:
Be that as it may, it is true that Adobe has declared "Save for Web" to be a legacy feature that will no longer be developed.
Yes, the new, replacing, method, is basically simpler (less options, too), but produces larger file sizes even if still smaller than AD, left: 24-bit PNG 8,208 bytes, right 8-bit PNG 5,958 bytes.
The link you referred to was not too informative but just let CC-based PS users know that the legacy feature is still available so not just clickbait. Irrelevant of course to users with legacy software.
No correct color separation anymore!!
in Affinity on Desktop Questions (macOS and Windows)
Posted
It seems that you have the document CMYK color space of your document set to Coated Fogra 39. If you at export time change the color profile to Coated Fogra 27, this will cause recalculation of all native CMYK values and also CMYK values of placed images with conflicting embedded color profiles.
In order to pass through existing CMYK color values, you need to match the document CMYK color profile with the target by using File > Document Setup > Color. If you assign the new profile, the existing color values will not be changed (this is the recommended method when the existing and target color profile do not differ much). If you need to convert, you should realize that this will also change K-only based values to four-color black, so if this happens, you need to set e.g. black text back to K-only based values.
There are also other considerations (e.g., when exporting using "PDF (Press ready)", the color profile is by default embedded. If you do so, you need to ensure that in Acrobat Pro, you are using the correct target color profile to simulate the output. If there is a conflict, you will bet apparently incorrect color values. In addition, there can be issues in having placed PDFs in the document that are not compatible with the export method and which cause rasterization of such content (and accordingly recalculated color values).