Jump to content

wigglepixel

Members
  • Content Count

    233
  • Joined

  • Last visited

About wigglepixel

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://www.wigglepixel.nl

Profile Information

  • Gender
    Male
  • Location
    : Utrecht, The Netherlands

Recent Profile Visitors

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

  1. +1 Using svg interactively in browsers and/or using stylesheets on them we need to be able to add css class names to elemenets. Right now we have to do this manually every time after exporting (breaks the workflow and makes it difficult to re-export a changed design) or write extra code to change IDs into classes (which needs extra work and unneeded extra code for each project). It would be nice and a lot easier if we could add these class names right within the layer names of these layers in Affinity (only the css class names, the rest we can do externally in other editors). So let's say our layer name is '#floorId.floor.floor1' in Affinity, that layer would then export in svg to an element with id="floorId" class="floor floor1" That way every user could use he's/hers own workflow by deciding which objects get a class/multiple classes and/or id. And we can also decide NOT to use IDs at all.
  2. [edit] hmm... I just reacted with a +1 to give the option to export Affinity Symbols as SVG Symbols because of performance reasons. But my view on the peformance part has changed; Not sure if things are improved in 2021 (guess not as svg isn't changed for many years, but perhaps the web rendering engines for svg have), but according to this old post, using SVG <symbol>s makes the SVG not faster, but even 50% slower in some cases as seen in a test: https://stackoverflow.com/questions/8604999/does-reusing-symbols-improve-svg-performance Still think having the option to export Affinity Symbols to SVG Symbols would be a nice addition and very useful in some situations. Especially when a symbol has a lot of graphics inside that will be reused multiple times and not being animated. Than, for use in browsers, it would load a lot faster and doesn't need the peformance part that much. But please, if this will be implemented in the future, make it an option instead of fixed export rule, so Affinity symbols will not always be exported as SVG symbols, but only when we ask for it, because of the above reason!
  3. Great work @Renzatic. Love this style! Both the vectorwork done in Designer for the labels/textures as well as the Blender scenes. Artistic and still cartoony, great mix!
  4. @Sean P thanks for the quick response. When I try it now, when opening an ai-file and cancelling the import, I see the issue again. On the files I test it now I don't see the same issue when not canceling during import, but I'm pretty shure I didn't cancel import before while having the same issue. I'll keep an eye on it as I can't replicate the same issue without cancelling the import at this moment.
  5. Windows shows some thumbnails of Designer files razor sharp and others, with exact same dimensions and dpi, and even exact same files but re-saved, blurry. Looking at the thumbnails below, the left one is the thumbnail of an exising afdesign file. The right one is the exact same file, but opened in Affinity Designer 1.8.5.703 and saved to another name. So for some reason newly saved afdesign-files get a very blurry icon while older files have perfectly sharp icons. I include the original afdesign-file as an attachment. buffer.afdesign
  6. After closing files that were opened in Designer they are still locked by Designer in Windows making it impossible to remove or rename them. Only after closing Affinity itself the files are unlocked. I'm pretty sure this wasn't an issue in previous versions of the program.
  7. Yes! Part 5 just went live. The era of Pixar, the beginning of mayor software packages, moving forward towards interactives and animations on the internet! 😎 Now that the second wave of the pandemic had arrived, we better have something interesting and full of content to read as well! Enjoy it everybody, hope you have as much fun reading as I had researching, writing and illustrating it! After this part there will be only one more part (part 6) to complete this series I've been working on since 2017 with preperation, research, organising, reading, illustrating, writing etc.! Collect them all 😉 Thanks a lot everybody for liking and (positively) commenting on previous parts! It motivates me to keep on writing quality blogs! English: The History of Interactive Computer Graphics - Part 5 Dutch: De Geschiedenis van Interactieve Computergraphics - Deel 5 @Alfred @Madame @Roger C @Wosven @GarryP @A_B_C @WatcherMagic @John Rostron @Renzatic @dutchshader @CLC @SrPx @haakoo @telemax
  8. This is exactly what I wrote in my post. But the problem here is: why does it needs to be reversed in the first place if the shapes are created by 'convert to curves' in the first place. IMHO This whole thing wouldn't be a problem if Affinity would always convert to Alternate Fill Mode. But for some reason I don't get Affinity converts texts to Winding Fill Mode, making this an issue with boolean operators as we see above, and in other issues here on the forum. @Sean P Is there a good reason why Affinity doesn't always convert curves to Alternate Fill Mode? As it seems like that would solve a lot of issues with the boolean operators.
  9. This bug still isn't solved in 1.8.5. As written above Expand Stroke only works when stroke alignment is set to the center. It's not working when alignment is set to in- or outside. Could this get some attention by Affinity to fix this?
  10. [edit] please read the last line of this post, which I think could be the solution to the issue I just did some more testing and found out how to make it work without tricks in the file I'm working on. In this file there are a few paths that work with subtract and others that don't (see previous post). So I tried reversing the paths of the 'non-subtracting' paths, and after that the subtract is working as expected. So it looks like the issue of boolean subtract not (always) working has to do with the direction of the paths not being the same as the path to subtract from. (But ofcoarse this shouldn't be an issue and should always work, so this is more of a workaround than a solution) Second video below (workaround 1): first paths without correction resulting in wrong subtract, then first reverse path directions of 'non-subtracting' paths before subtracting resulting in expected subtract. (btw, it would be nice if this forum would let us move videos around in a post) Hope this helps the developers to fix the issue. [edit] workaround 2: changing fill mode of all paths to alternate I just found out that when changing ALL paths needed for the subtraction to 'Alternate (even-odd)' fill mode, subtraction works as expected, no matter the direction of the paths, but when switching to 'Winding (non-zero)' we get the subtraction issues back again. In the video below all paths are in fill-mode 'Winding (non-zero)' first. And you see this is causing issues when subtracting. After that I change the mode to 'Alternate' and subtraction works fine. Changing it back to 'Winding' again and subtraction fails again. So to me it seems like 'Winding (non-zero)' is throwing these issues with the boolean subtract operators. And now I also understand why @anon2 's workaround works: convert to curves ALWAYS puts the created path/curve into 'Alternate (Even-Odd)' fill mode. And with that fill-mode there are no subtract issues. So the workaround in there is basically not the non-destructive subtract, neither the 'convert to curves', but the switch to 'Alternate' fill mode. So my guess is that the issue would be fixed if subtract would automatically switch all selected paths to alternate mode first before subtracting. subtract-works-when-all-paths-are-in-alternate.m4v workaround 1 (when in 'winding' mode): reversing direction of 'non-subtracting' paths before subtract: boolean-subtract-works-when-same-direction.m4v
  11. After checking all nodes again and again in a graphic today I came to the exact same conclusion that subtract is sadly not working anymore. I'm pretty sure this was working before on the exact same file in an earlier version of Designer. Just to give another example of it not working anymore see video below. All shapes are closed and there are no overlapping nodes or weird things. Everything is checked. Also all windings are the same, so subtract should just work without issues, but it does not. I found out though when changing the fill mode of the lowest layer to Alternate (even-odd) and subtract after that the result is okay. But I don't want that fill mode and when changing it back to Winding (Non-zero) after subtraction it destroys the result again. @anon2 Thanks for this workaround. When applied to the vectors as below example it works! Hopefully this info helps the developers to fix it so we can use destructive subtract soon again in the next version (BTW Using Designer 1.8.5.703 here) boolean-subtract-not-working-anymore.mp4
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.