Friksel
-
Posts
502 -
Joined
-
Last visited
Posts posted by Friksel
-
-
35 minutes ago, PaulEC said:
This seems to happen with other apps as well; why not just use the Taskmanager?
Because hard killing an application with the task manager is never the way to go for obvious reasons
-
When trying to quit the application because a file takes a long time to load that doesn't seem to be possible (without using taskmanager) as Designer asks us to wait for the load to finish.
IMO it should always close the application, no matter what's currently busy. Especially because one of the reasons to close the application could be to not wanting to wait for a large file to finish (or might be stuck forever).
Please make Affinity close immediately when exiting to prevent us needing to use the taskmanager to do so!
-
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! 😀
-
On 2/29/2020 at 12:22 PM, Heriberto Reinoso Gallegos said:
Please guys this is not only an ideal tool it is absolutely necessary in any case. I am sure you can do it. I've installed the latest version of Affinity Design with so much hope that this would be done already, but... nothing still. Please, Please, try to fix this. Thank you.
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.
-
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
-
Guys, I appreciate your enthousiasm and it's great to see on your systems it's working and it's probably valuable information for devs to know this issue doesn't occur on all systems out there, but I mentioned this thing in the BETA forum.
This is BETA testing, I bumped into an odd issue that shouldn't be there and posted this on the beta-forum. I am not trying to find a workaround (like I would when using the stable version for real work), I am mentioning this issue here so devs know about it and can fix this.
-
Just for people whos Chinese is a little rusty, like mine is, here's a google translate
-
2 minutes ago, walt.farrell said:
Good. So it's not that "documents now get Wide Gamut by default (which is a major issue). It's one specific preset you have that now gives Wide Gamut (which may affect fewer users, depending on what the issue is).
Serif will probably want to look at one of your files: %appdata%\affinity\designer\1.0 (beta)\user\doc_spread_presets.propcol to see if something has gone wrong with it. (Once they're back from Holiday, of course.)
No, that's not the right conclusion. Please read my posts again and watch the video
-
15 minutes ago, walt.farrell said:
One other thing, @Friksel: The color space and profile would come from your page preset. Have you checked to see how you have "FHD 1080p (1920x1080; 16:9)" defined? Maybe it's an issue with your preset, or an issue specific to interpreting something in user-defined presets.
Yes I did. It's wrong in the preset.
To indicate this further; these are my color preferences in the beta (nowhere it says Wide Gamut):
And this is showing when creating a new document by preset (all presets show Wide Gamut and I never ever switched to WIde Gamut myself):
-
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.
-
On 12/19/2019 at 5:00 PM, R C-R said:
True, but the stroke Style icon buttons to its left does do that. The first one (the circle with the red slash) won't show as selected if the stroke has any non-zero width, even if it is 0.00001 px.
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:
-
@walt.farrell Yes, I had checked the preferences, as I wrote in my post; it's on sRGB. Still the document profile is set to Wide Gamut. And that's not the case with the current stable version. This is only wrong in the beta and I never switched it.
-
6 minutes ago, Rondem said:
Like you noticed it depends on what color profile you select.
If you pick sRGB its normal.
Yes, I know that. But as I wrote above it shouldn't be on Wide Gamut per default in my humble opinion, but on sRGB. I believe setting this to Wide Gamut in default document profiles is not as intended and not desired behaviour for most people and is causing confusion and problems, so something to be mentioned to devs for this beta.
-
4 minutes ago, haakoo said:
Your images have gone from the post so nothing to see
They are back now. Thanks for letting me know @haakoo
-
I initially started this post with the below about weird colors in the color palette on the Color Chooser dialogs. But looking further I see now that the document color space in the beta is set to 'Wide Gamut' instead of sRGB. Not sure why that is, but it's causing color problems as most people don't use Wide Gamut screens to view their work and a lot of people are working for the web, which normally only shows sRGB anyway. People using a bigger/different color space for their work will switch the space to their needs anyway.
So I'm sure setting the document colorspace to Wide Gamut is not intentional. Looks like the wrong index is set in the Color Profile dropdownbox in the document settings.
(BTW the Working profile settings in preferences are still on sRGB)
My guess is there is an offset problem with the dropdown-index (zero vs one-based?) or a new space is added without changing the default index or something?, as the sRGB itemindex is 1 higher then Wide Gamut:
----
Below was my initial post. I leave it just to indicate confusion I believe more people would/could have with a default to Wide Gamut:
When using the color chooser the colors in the color field seem to be off and are different to the current stable version. Looks like they are clipping or something or using the wrong curves or something.
This is for example the Hue field as it is now in this beta. As you can see the transitions are pretty harsh and even show artifacts:
This is the same field in the current stable version. So as you can see it looked way better and right in the current stable version and didn't show any artifacts:
Looks like the same goes with all color modelfields, like rgb. This is the rgb field on the current beta and you can see it's the same problem again: artifacts and looks oversaturated and clipped (shows transitionlines):
While the current stable Designer version shows this as expected and the right way:
-
On 9/25/2019 at 9:20 AM, Sean P said:
Thanks for the video! That is very helpful - I've been able to reproduce the issue and it looks like it is being caused by the 'Edit Fill' dialog. I'll get this passed on to development.
@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
-
12 hours ago, walt.farrell said:
Sometimes there is a very brief message shown to the effect that the installation needs to update some system component (some COM component?). At that point, Windows automatically does a hard reset and restarts when the installer is finished.
It's happened to me twice in the past.
@walt.farrell Thanks for your response. Yes, that's exactly what I've saw. I got a dialog asking me to close 'COM'. I didn't know what application 'COM' was, so I closed the currently open Affinity Designer (non beta), because that was the only logic thing to me to be closed. When I clicked the dialog button the computer started to restart. But there was no message at all to indicate that that was going to happen. I was glad I didn't have any project open in other software at that moment!
If it is really meant to restart the computer, I would at least expect some confirmation box with that info showing up so we know it's going to restart, so we can save our work on other programs or maybe restart later. Still I wonder if this restart is really nececary and on purpose.
-
12 hours ago, walt.farrell said:
You need to go to Preferences, User Interface (UI), and adjust the number of decimal points displayed for values displayed in points. It defaults to 1, where anything from 0 to .05 would round down to 0, and anything from .05 to .099 would round up to .1.
Thanks @walt.farrell. Never knew about that setting. That helps a lot indeed!
QuoteThat would suggest you have set your decimal points to at least 3 decimal places. Is that correct or is the above a mistake?
@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!
-
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.
-
52 minutes ago, adirusf said:
Good news with the latest beta release 1.8.0.526
Fixes- Improved Expand Stroke
Wow, I can't believe my eyes, looks like it finally happened:
Even the positioning of the anchors seems to be right on this first test of a circle, that looks promising!!
-
I just tried to install the latest beta (1.8.0.526) to tryout the hopefully fixed outline stroke, but without any notice or messagebox of whatever the installer causes Windows to crash and restart during the installation out of the blue. That can't be meant to be like that.
Running healthy Windows 10 home with all important updates installed.
For the record: this was no Windows update restarting the system.
[edit] the program did install though and seems to work so far
-
Edited the initial post with the profile info
-
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?
-
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 completelyTrying 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.
[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
How to convert and import DWG into designer without Autodesk?
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
Hi,
I need to open a received DWG-file into Designer, but never used that file format before. Unfortunately Designer doesn't support DWG and according to a six years long open request thread elsewhere on this forum no support would be expected in the near future.
I'm not using Autodesk, nor Adobe anymore, so can't use that to convert the file format. I saw that Inkscape is able to import dxf files, but not dwg files either.
(using Windows btw)
Other than this I only see online converts, but that's a no go as I can't put private client files through there for obvious reasons (a free product is free for a reason).
Anybody here got a workaround to convert DWG to a vectorfile Affinity can import (Preferably SVG or PDF)? Any experiences with installable desktop converter tools either payed or free that can do this? Would it really be a one to one conversions, and/or are there differences in versions in the DWG fileformat I should be aware of (or things that could get lost during a conversion)?
[edit] Just did a quick test with AutoDWG (DWG to SVG Converter) to convert the DWG to SVG and than open it in Designer and that seems to work. But it's generating huge files with very inefficient conversions to vectors in the svg (could very well be inefficient in the original though). I'm not experienced in the DWG fileformat, don't know about DWG file format versions/compatibilities issues and at the moment I am not familiar with the original design as I can't view the DWG. So not sure if I am missing something in the export. So still open for experiences on the best workflow or things to take into account!
Thanks a lot!