matt.baker

Looks like it is the configuration on my work machine. Laptop at home works fine. Very odd.

So far it has been consistently failing even after closing the software. I will try it on my laptop at home (Windows 10 x64 Home Premium) to see if it happens there as well. Video of the effect https://drive.google.com/file/d/0B9zQu9iLZE5OUXdzTi1QTkRubFE/view

This has returned for me. It also happens on the gradient fill opacity numeric fields. Steps that reproduced for me: New document: web pixels New rectangle shape Fill option in top toolbar: set to gradient tab Left colour node active. Opacity numeric: select and type 50. Press enter. Right colour node active. Opacity numeric: select and type 50. Press enter. Back to opacity left numeric select type new number. Press enter. - Enter no longer works and arrow keys etc.

What are the chances of having a dedicated feature request site (rather than a forum) that allows up voting, marking as duplicate (and referencing the duplicate), feature/idea status (declined, duplicate, in development, planned, new etc.) and a way of filtering by status. Very similar to LabVIEW Idea Exchange: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas Just a thought.

Thanks Sean. That makes perfect sense now. Thanks for explaining.

Hi Jon I'm running Windows 10 Pro 64 bit Version 1607 Build 14393.321. Edit: How bizarre - I've just tried it again and it's working as expected now. I'll let you know if it comes back.

Installed today, but in the about page it says 1.5.0.25 (RC) not RC1. Is this expected?

The white highlight on the transform tool does not follow the active pin position. See image below.

The fill and stroke numeric fields for a shape on the top tool bar are buggy. After entering a value and pressing the enter key they no longer allow the backspace, delete or arrow keys (text caret does not move) when re-entering values. The ones on the palettes work as expected. Bug was present in 1.5.0.24 as well.

I've just downloaded the latest Windows beta 1.5.0.25 (RC) and it's now fixed (the change history mentioned user variables in this release). Before, I didn't have the light grey row. Also, I agree, it definitely needs more features such as a way of creating global/document variables that can be referenced by all of the slices/exports. Thanks

Thanks bellyanalytical I tried clicking and double clicking below the name column, but not had any luck. Maybe it's because I'm using a beta release. Could someone from the Affinity team jump in with some official documentation on this feature please?

That makes sense. Thank you for explaining why it won't be added. I guess it's not too bad. I originally played around with the performance values then thought 'Crap. What were they originally set to?'. You're right Jon, it is a non modal window. Just assumed otherwise :)

On the export options for slices I see a 'User variables' section. How can I make use of this? Thanks

Are there any ways to add additional document information such as its revision and title? I would like to add this information when I export the it as a PDF with the automatic registration marks etc. At the moment the 'Include page information' just adds the file name and artboard name (example export https://goo.gl/fCyFCI). Alternatively, how do YOU manage the revisions of documents in the exported files? Thanks

Great! Thanks Chris

Any changes made in the preferences window are applied when the close button or cross in the top right is clicked. There are no ways (that I can see) to cancel changes made. Dialogs like this should (in my opinion) always have a way to cancel and not apply changes. Also, the changes made in the performance tab don't save after I close and reopen the software.

The UI colour sliders are still buggy in the user preferences. As soon as the UI gamma slider is adjusted, the top two sliders become unresponsive and only change to the new positions once UI gamma is changed again or the user preferences are closed and reopened. The UI gamma slider is also jumpy (lots of processing?) when moving.

To add to this, Office viewer reports the Horizontal resolution as 81.55 dpi and 81.64 dpi for the Vertical resolution. I would have expected these to be identical and match the Affinity document. EMF test.zip

Reference ecd0806d-bba2-4b80-965d-d313fd786cf7 File -> Export -> WMF tab Click More... Click close on the Export Settings dialog. Unhandled exception 0xE0434352

I'm unsure whether this is a bug with Affinity or a limitation with the EMF file format, but when exporting the attached document as an EMF extra white space is added to the right and bottom edges. I have verified the white space is present in 4 different applications (Microsoft Office, LabVIEW, Inkscape and an online converter to PNG) so I'm assuming they are correctly rendering EMFs. I've tried changing the resolution to 96 dpi instead of 72, but the same thing happens. It seems to be only certain paths/sizes. If the ascpect ratio of the original are 1:1 it works correctly, but if it's say 100x75, it's most noticeable. If I open the EMF in Affinity, it renders without the extra white space. If I open it using the Microsoft Office 2010 image viewer, it reports the size as 11x10px even though the Affinity document is 12x11px. A similar thing happens if the original image is larger. It's almost as though Affinity is exporting partial pixels (rounding error?). Inkscape has now decided not to render the EMFs (displays as a white document) so I'm unable to provide a screen shot of that case. Not permitted to upload an EMF, so here's a link: https://www.dropbox.com/s/pin3a6wo7nesypv/Up%20arrow%20Affinity.emf?dl=1 More test files at 72dpi: https://www.dropbox.com/s/z2cajl6vf7mxj41/100x75.emf?dl=1 https://www.dropbox.com/s/hm6fu25nt6dxnji/100x100.emf?dl=1 https://www.dropbox.com/s/yiagm82oqj9332o/100x120.emf?dl=1 Up arrow.afdesign

Thanks Alfred. I spotted that as well after I posted :) It does work, but it still seems like a bug to me.

1. The blue colour node is hidden under the red node with no way to select it (that I know of). Suggestion: make end nodes delete-able and move-able (match Adobe's implementation). This would allow the gradient to be easily rearranged. I.e. If you want to change the final/end colour there is no easy way of doing that. With the Adobe implementation simply dragging the end node inwards past another node will swap the colour. Adobe's implementation: 2. Mentioned before elsewhere, but the reverse operation on the applied fill doesn't take effect until other fill parameters are modified after.

Thanks for the explanation and tip, Matt. That clears things up. I guess it kept the metadata for the two elements from the original document when I pasted them into a new document.

Why does Affinity insert unnecessary transforms when exporting as SVG? With the example document, the SVG export gives: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 12 11" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;"> <g transform="matrix(0.8,0,0,0.916667,-446.4,-374)"> <rect x="558" y="408" width="15" height="12" style="fill:rgb(235,235,235);"/> </g> <g transform="matrix(1,0,0,1,-561,-409)"> <path d="M567,411.501L569.499,416.499L564.501,416.499L567,411.501Z" style="fill:rgb(153,153,153);"/> </g> </svg> This can be simplified to: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 12 11" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;"> <rect x="0" y="0" width="12" height="11" style="fill:rgb(235,235,235);"/> <path d="M6,2.501L8.499,7.499L3.501,7.499L6,2.501Z" style="fill:rgb(153,153,153);"/> </svg> The original seems an overly complicated way of doing it.Up arrow.afdesign Up arrow Affinity.svg Up arrow Modified.svg

Bug: Gradient fill's reverse button doesn't take effect until the the type is changed. Same behavior in previous releases as well.