Jump to content

Friksel

Members
  • Content Count

    446
  • Joined

  • Last visited

About Friksel

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Yes, long standing, like Elton John once sang: "I'm still standing" Would be great if it could get some attention to get it fixed after all this time though! 😀
  2. Uh... please speak for yourself. I understand a lot of people think this is a very convenient feature for their workflow and I am sure a lot of people would be very happy with it and miss it when being used to use it in illustrator or other software. And I understand that pain. But as an illustrator and designer for years and coming from Illustrator I never needed this feature one single time. So please understand 'absolutely necessary' doesn't count for everybody. We all have our own 'absolutely necessary' feature wishes, but 'absolutely necessary' could be put in perspective a little more here I'd say, because there are also other ways to do this for the time being; like global swatches as @MEB wrote. Once you get the hang of using Global swatches they are pretty amazing.
  3. @Callum BTW Could somebody move this thread to the current Designer issues forum, as now it is in the 'pre 1.7' but the bug obviously still is around in the latest version (1.8.0 now). Thanks!
  4. Sorry Callum, but it's hard to believe that fixing a single bug or even all bugs, should take four years. I am not angry or whatever, don't get me wrong, but I am indeed pretty frustrated once in a while about this. As this is taking way too long and we have to professionally work with and rely on this software. Even for a small team. I've seen software being created by single developers solving bugs a lot faster. I understand you are trying to help here with your reaction and would probably like to write something more optimistic yourself, so no offense at all to you. And I know you guys are (finally) fixing some bugs last months and that's very great to see. On the other hand, also new bugs are introduced. I just hope some of this basic functionality will be stable at some point in the time in the near future.
  5. @Callum This issue, I reported in october 2018, but already seemed to be reported years before, on 19th of april 2016 (!!), of which you responded it was logged with your developers, STILL isn't solved in 2020. It's just amazing how long you guys let bugs lie around before fixing. Which is strange, because SVG 1.1, which is used everywhere, already is standardized and around for 17 (!!) years (since 2003). https://www.w3.org/TR/2003/REC-SVG11-20030114/ Version 1.8 still doesn't show the red stripes of the exact same file of the English flag:
  6. Not sure how this could be a feature. As a user I would rather like to know the exact output size instead of guessing if Affinity would save this to 3397 or 3398 px height. My 2cts
  7. In the stroke panel there are four linestylebuttons starting with the 'no linestyle' button, following by the solid, dash and texture line style buttons. They are not only buttons but indicators as well to tell the user which type is currently selected in the selected object. When an object don't have a stroke and we change the width to say 1px, the 'solid Line Style' automatically gets selected to indicate the user there is now a stroke active. Which makes sense, as the stroke has gone from 0px to 1px. But when we now change the stroke back to 0px, the buttons don't get updated. It should have gone back to the 'no linestyle' instead, but it doesn't. This is a problem, because strokewidths may be below zero, like 0.0001px and decimals might not be visible (as they need to show enough decimals to show the change, as set in the preferences) and when the line style buttons don't get updated there's no way to see as a user if there is no stroke active or such a small stroke value that gets rounded to the bottom when there aren't enough decimals to show the value. So 0px could be: no stroke - zero width, but could also be 0.1px or 0.006339px or whatever. But as a user that's not always possible to see now. linestyle-not-updated.mp4
  8. That's not true. Try putting the strokewidth to 1px: you see the stroke buttons are automatically switched to the line-icon to indicate there is a stroke now. But when setting the stroke back to 0px after that, it never switches back to the non-stroke iconbutton. So there's no way to tell than if the stroke is 0px or 0.00001px. If this would work as you described and therefor as expected, that would indeed be a nice addition to the interface to be able to tell if there is a border or no border width. But it's obviously not working at the moment. So just filed a bug:
  9. @Sean P Looks like this one is fixed in one of the latest betas as I see it working in the latest beta if I do exactly the same as I did in the video before. Nice! Thanks
  10. Thanks @walt.farrell. Never knew about that setting. That helps a lot indeed! @carl123 Obviously the way the software is build now we should. It would be nice if we didn't need to, because 0.2 doesn't have to be written as 0.200, but I understand the precision float number problem and I think the solution to make users pick the precision themselves is not bad at all. The only thing I still think is strange is that when a value is rounded to zero the textbox doesn't give users any clue that the value isn't zero. In my opinion zero is a special case, because when setting a border to zero that implicates that there is NO border at all and having no borderwidth would result in no border export either. So if I were Affinity I would handle the zero differently and add some indication in the UI that the value is not exactly zero, but rounded to zero in the display only. Like showing an asterix after the value textbox or something, to indicate that the value is not exactly zero, but a small number, rounded to zero. '0 px' * But we can't have everything and being able to set the decimals ourselfs helps a lot. Thanks again @walt.farrell ! Great tip!
  11. When setting a stroke width below zero, the textbox shows this when it's above 0.1. So widths like 0.2, 0.3, 0.123 are shown as expected. But when the width is below 0.1 Affinity suddenly acts like there is no border at all; it shows zero instead of the real value. I'm using widths below 1 a lot for digital animation work (using svgs), like zoom in animations, also widths with values below 0.1. So for the work I do this is a pretty common scenario I bump into many times. And when widths are below 0.1 there's no way in reading somewhere in the user interface there is in fact a width (not zero) and what that value currently is set to. This is what we see now when the strokewidth is below 0.1, which is obviously telling us users there is no width, while in fact there is: I understand developers don't want to show all digits and have to deal with rounding the real values, but truncating to zero is just not right. Why not display '< 0.1' instead so the user can see there is in fact some width so not zero. Than when a user hovers over the width slider or the textvalue inputbox with a pointer it can show the real, full number of the width, in a tooltip so we can always see what value the width is really set to. Like this: it shows '< 0.1' if the value is below 0.1 and when the user hovers it shows the real/full value: I don't believe this is a lot of work to build in the software, but it would definitely help communicating to us users a lot better (and not confusing in acting like the border is zero, when there is a border set). [edit] I see now I accidentely posted this in the publisher forum, although it was meant to be in the Designer forum. I leave it like this because it affects all three programs anyway.
  12. After some more testing I just found out it has something to do with the Printer Profile I obviously created earlier (so guess it's not the first time I print with the software). When not chosing a custom printer profile from the list everything seems to work fine, but when chosing a printer profile the thing happens as described above. Maybe those printer profiles were created in an earlier version of Designer and are not compatible?
  13. Normally I don't work for print, so this is probably the first time I use print in Affinity Designer. I have a file with a simple shape on it only and when I try to print this to the printer the following sequence is consistent: - Printing the first time: Affinity Designer doesn't do anything, the printer isn't printing - Printing a second time after this: Affinity Designer crashes and closes itself completely Trying the above steps again after restarting again and again everytime the exact same thing happens. The printer is working fine, never had any problems with it and when I print with other software there's no problem at all; the printer immediately prints without any problem in other software. See attachment for the used designer-file. testfile.afdesign [edit] The problem seems to be in the custom printer profile file. When using the default settings there's no problem printing. But when using an earlier saved printer profile the problem as described above arises. I've compared the settings of the default settings with my custom printer profile, but the only thing that's different seems to be that the default looks at 'defined by driver' for paper format and the custom profile is set to A4. But when I set the default profile to A4 too it still works, so that's not the problem. The only difference I notice between the profile-settings and the default settings is that in the graphic dotted red lines appear when using the custom profile from the dropdown. Not sure what that means, as all settings in all tabs I compared seem to be exactly the same. I get the impression the older printer profile files are not compatible with the latest Designer version or there is a problem in loading/interpreting the profile file correctly? This is how the graph looks in default settings (I only changed paper size to A4 here, but it also works when set to printer default): And this is how the graph looks with custom settings loaded by profile (see red dotted lines) Here's the profile: my-print-profile.profile
×
×
  • 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.