Jump to content

sepwilson

Members
  • Content Count

    8
  • Joined

  • Last visited

  1. Working at 144 DPI would make sense (and the presents for Retina iOS devices default to 144 DPI) but it has the side-effect of making the "Pixel View Mode" preview @2x and "Retina Pixel View Mode" @3x. This isn't what we would expect. When designing for iOS/Mac, we would expect "Pixel View Mode" to render at @1x (i.e. 1 pt = 1 px) and "Retina Pixel View Mode" at @2x (i.e. 1 pt = 2 px). It therefore makes more sense to set the DPI to 72. Slices are exported correctly (i.e. correct scaling and DPI setting in the file's metadata) for @1x (72 DPI), @2x (144 DPI) and @3x (216 DPI), and the "Pixel View Mode" and "Retina Pixel View Mode" render at @1x and @2x as one would expect. Can someone from Serif comment on this?
  2. Copy/paste via the edit menu (or, more accurately Cmd+C, Cmd+V).
  3. > Have you tried to refresh the Finder window? Finder windows always stay up to date using file system notifications. There is no refresh command in Finder. If a file's modification date is not changed following a write then it's either because the app didn't write to that location (or it intentionally prevented the file modification date from being updated, but I find this very unlikely). > By design, you shouldn't be able to open the file in two or more computers simultaneously. We are always careful not to do so in relation to DropBox. Files are not shared between computers when using VCS such as Git, Subversion (we always have our working copies stored locally). Cheers, Simon
  4. It appears that Affinity Designer does not always write changes back to the original file. These changes are then flushed when the document is closed. This behavior can easily be observed in Finder by noting the file modification date and/or size, which do not change when the file is saved in Affinity Designer. However, the file modification date and size are updated once the document is closed. It appears that changes are being written to a temporary document in another location while the document is closed and then "committed" to the original file only when the document is closed. This behavior may be dependent on file size, at was only exhibited for larger files -- my smaller files appear to be written back to their original location immediately. This behavior is problematic, as it breaks our workflow in serious ways. For example, without closing the document: i) Other computers and users that share the same DropBox account don't see changes, even though they were explicitly saved in Affinity Designer. ii) Modifications may not be backed up to Time Machine as long as the file remains open in Affinity Designer. iii) Changes will not be flushed/committed back to the original file in the event that the app crashes. iv) It makes working with a version control system such as a Git or Subversion problematic, as the VCS will not "see" the changes until the file is closed. This interrupts our workflow where we expect to be able to commit changes to the repository without having to always close the document to ensure that the changes are written back to the original location. I have no idea whether this behavior is a bug or by design, but it needs to change. Buffering changes to a temporary location is OK to ensure that data is not lost by a crash, but changes should *always* be written back to the original file location whenever the user explicitly saves the file.
  5. Boolean operations can result in incorrect geometry. This seems to most often happen with shapes with rounded corners. Sometimes the problem can be worked around by converting the shape to a curve before applying the boolean operation, although this shouldn't be necessary. See attached file and screenshot for an example ("Example Boolean Bug.afdesign" and "Boolean Bug 1"). Another problem often exhibited when performing boolean operations is faceting around the edge of filled objects. Combining two layers by grouping does not exhibit this issue. See "Faceting - Boolean" and "Faceting - Grouped" (attached) for examples of this behavior. The only difference between the geometry in these two screenshots is that the two objects were combined with a boolean operation in one and grouped in the other. Example Boolean Bug.afdesign
  6. Drag scrolling is extremely slow, especially at high zoom levels. E.g. I want to extend the width of a shape beyond the right visible edge of the document, so I click drag the center-right drag handle of the object with the mouse and drag to the right. Once I hit the right edge of the art board view drag scrolling starts, but this is excruciatingly slow at high zoom levels to the extent where it would take several seconds to scroll hundreds of points. In fact it's so slow it's barely feasible, so I often end up zooming out several levels to resize and then zoom in again, which interrupts my editing context. Slow drag scrolling doesn't seem to be related to poor drawing performance as drawing and scrolling speed is otherwise very good, so I suspect this is more likely related to the acceleration algorithm used. Please tweak this algorithm to improve responsiveness during drag scrolling.
  7. For example, I select a layer and nudge one point to the right by pressing the arrow key, but often (I have been unable to determine a pattern as to when exactly) the layer will jump a random number of points in another direction, as if the nudge is being applied to out of date layer/object coordinates. Often the jump is on multiple axes which can break alignment. At large zoom levels this can mean that the layer's contents disappear from view completely. After the initial jump, the nudge function then works as expected. This issue occurs both when nudging a single point and 10x points (with the shift button pressed). There seems to be no workaround. Undoing and then re-attempting the nudge results in the same random jump in position. The only workaround is to a) accept the jump in position and This is an extremely annoying bug which should be addressed as soon as possible.
  8. Layers are not pixel aligned when pasted, even when the "Snapping Manager" is set up to snap all geometry to pixels and "Force Pixel Alignment", "Move by While Pixels" and "Snapping" are enabled in the toolbar. As a result, I have to manually pixel align every layer pasted by editing the values of the x and y fields in the Transform panel. This gets old really fast. It would be great if Affinity Designer would automatically pixel align all content when pasted.
×
×
  • 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.