Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

lacerto

Members
  • Posts

    4,845
  • Joined

Recent Profile Visitors

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

  1. As APhoto macros are kinds of black boxes, here's an .aphoto file with a history starting from a grayscale image that has L, a and b as distinct layers, showing a procedure of converting the image to Lab using spare channels. I think this was pretty much what the macro above did (though it might have been built on a bit different starting point). Grayscale2LAB.afphoto
  2. Another issue [specifically within Affinity apps] is that even if PANTONE colors were given in L*a*b space they cannot be shown in that color space, unless the gamut of the document color space is also L*a*b (or wide enough to cover PANTONE definitions). In practice spot colors are typically used in CMYK color documents in which case many PANTONE spot colors look quite desaturated and unrealistic.
  3. I think that there is a bug (or kind of a silly omission) in the code since if you manually expand the image groups, the Locate in document button becomes available (non-grayed out) and you can then activate the selections on the canvas and delete the images. The Locate button should be available even if the image groups are not expanded because they are actually already selected within the groups. I guess this is still a bit quicker than first using the context menu to expand all layers within Layers panel and then selecting image resources from within the Layers panel? I guess it much depends on whether you have the images large enough on the Layers panel so that you can recognize them from the thumbnails (note that you can change the size of the layer thumbnails).
  4. I played a while with v.2.0.4. Divide operation (now mainly on macOS) but still could not get it work consistently. But the feature is broken on both platforms, and now I got different behavior also on macOS depending on font, and also depending on whether text based objects (whether still as frame or artistic text or converted to curves and merged) were involved or not. So I got bored in the middle of trying to produce a similar chart of mere Division operation in different situations (both shapes filled, only top or bottom shape filled, neither shape filled, and then performing Divide simple and Alt+Divide), because getting so varied and inconsistent results. I am not sure about usefulness of getting different results for Division depending on having the Alt key pressed down or not. I would prefer the operation to behave similarly as Illustrator so the operated shape areas would always be retained after being divided, no matter if filled or unfilled (so no area would ever be lost and could afterwards, after division, be filled if wished). I can see some limited usability in Inkscape kind of Division where the division is confined within the area defined by the top object and the rest is removed (disregarding the fill state), and perhaps this could be a possible functionality for holding down the Alt key during the operation.
  5. Ok, thanks for clarifying, I need to examine this operation more closely to understand it better. I have previously thought that Boolean operations are pretty similar in different apps, and to certain extent they of course are, but they work differently in Affinity apps and e.g. CorelDRAW, Illustrator, VectorStyler and Inkscape, and also use a bit different terms.
  6. But does it in practice? I meant promotion much in the sense that including Silicon distribution might be a kind of a requirement to be able to deliver via App Store in the first place [and a means to get the developer get their app support as soon as possible the new architecture] -- and then the fat binaries (Universal apps) would basically be a pragmatic requirement for also ease of use?
  7. I think that there is a chance that separate deliveries are if not prevented then discouraged in order to promote that latest and greatest, especially if the method of distribution is Apple Store? Just a guess. There are these kinds of restrictions also for delivery via Microsoft Store (I am not sure but I think that if separate 32 and 64-bit packages are wanted to be delivered, it must happen off the MS store...).
  8. 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).
  9. 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.
  10. 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)
  11. 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. subtract_issue_v01.afdesign subtract_issue_v02.afdesign 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).
  12. Subtract as a compound operation to get it non-destructive. Erase always rasterizes on export. test_compound.afdesign test_compound.pdf
  13. 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: unpopulate_selected.mp4 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.
  14. 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.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.