• Content count

  • Joined

  • Last visited


About Ben

  • Rank
    Fully-breaded Cat

Profile Information

  • Gender
  • Location
    Nottingham, England
  • Interests
    Computers, music, films, photography.

Recent Profile Visitors

636 profile views
  1. It will be because you have Snapping Candidates set to "Candidate List". It keeps a track of six most recent objects you have created or selected. Older objects are removed from the list. Change this to "Immediate layers" if you want to snap to all your layers (within scope of the same layer). You should watch the tutorial:
  2. The issue is due to how we maintain ownership of the document file. We keep the file handle open, with flags to indicate a lock on the file. We assume then that no other application can also modify the file while we have it open (we do other checks for cloud storage, etc, making changes). If the file handle is lost then we currently opt to close the file for reasons of data integrity - we cannot know that what is on disk matches what is in memory without fully verifying the data. When your PC goes to sleep, it is likely that any file handle are closed by the system. We currently don't try and reopen a lost file handle. This is something that we will look into doing soon, but it is not trivial. The method for verifying data needs to be fast and reliable.
  3. I thought this one had gone away. It is a bug in Apple's save dialog code. It's not something that we can fix, but we'd not heard of it in a while. What version of OSX are you on?
  4. The snapping you are talking about may seem trivial, but consider the logic that needs to be employed. It is a special case that would need to be crafted just for snapping pie angles. It requires a test to see if there is an equivalent pie shape to which you would want to snap - something that would require some quite involved logic. It can be done, but this scenario is fairly niche. It's simpler just to duplicate the pie, swap points, and drag the other point around to continue the sequence. I may get around to adding further snapping for shape points at a later date, but anything that is added will have to work on generic rules - otherwise we are pouring time into solving problems for just one or two people.
  5. Fair point - I'll pass that on as a suggestion. Adding the stroke is effectively doing the same as what I suggest though - expanding the geometry behind to fill the gaps.
  6. Just one bit of advice - if you are writing your own PSD reader/writer and have similar problems - you need to compare how Photoshop has written your file and work out the differences. Starting with a small file will help. That can validate your assumptions of how each struct is formed, and what values to expect. We found out that the documentation has some areas that could be better explained, and comparing the doc against an actual file can help resolve that.
  7. Moving the ruler and grid origins will be in 1.7. The work has been done, but was part of a major reworking that couldn't be included in 1.6. It will go through Beta when we get into the next cycle. Due to the changes incurred it will require a full Beta cycle, hence why it is going to be in 1.7.
  8. The white stripes are not due to gradients, it is to do with the fine line between your polygons - it is the white of the document behind the shapes that you are seeing. This is due to how rasterisation of vector shapes work. You need to extend your objects behind another to ensure that these edges do not occur.
  9. Start up both apps and close them down... then start them up again. The app saves a file at start-up that we use to detect compatible copies of installed software. Hopefully the edit-in options should become enabled.
  10. This is a tricky one. We have registered .affinity as a file extension, so (as is the Unix way) it is treating it as a file, not a folder. This is down to the behaviour of the standard OSX file open dialog - something we have no control over. I have tested it - even though it says it is a folder, double clicking on it attempts to open it as a file (which, of course, it isn't). Unfortunately, not sure what we can do about that. I doubt we will unregister .affinity as one of our file extensions.
  11. Yes - snapping is temporarily disabled... until you move the mouse to somewhere that is less busy and snapping can be done. But, snapping is not disabled as such - if you move the mouse it will continue to attempt to snap. If it says Timeout, then snapping has not been performed at all as the calculations were aborted. It didn't get to the point of deciding on the final snap offset. There is no part-snapped situation as that would lead to less helpful results than just aborting snapping.
  12. Yes - it is entirely intentional. Due to the nature of snapping it is not possible to predict how much time snapping will take. I added a timeout so that if you mouse over a really complicated area of the document, it would time out rather than hanging the app. This is a compromise for people who like to leave all the snapping options turned on. I've already done some work on snapping improvements which will feature in 1.7 - that includes using multi-threading to split up and order snapping calculations, and optimisation of inputs to the snapper. This will make a huge difference to performance, and as Matt says, will reduce the chances of snapping timing out. Expect that as soon as we enter the next round of Betas.
  13. Thanks for raising this issue - we have closed it as "by design".
  14. We also won't be adding any diagnostic tools to help other developers debug their PSD/PSB files. We have spent considerable time ensuring that we follow the specification, allowing for certain errors in PSD files from other common vendors. Reporting an exact file location is subjective because the error that causes the misalignment might occur earlier in the file. I had to work out the actual error through debugging. You can assume that if a file fails to open in Affinity and it reports a bad signature or a misalignment, then the file is badly formed. (Especially true if the file can be opened if you save it out again from Photoshop).
  15. I've looked at the PSBtest_8bit_BUG.psb file. It is badly formed. It looks like you are writing the Global Layer Mask Info length as 8-bytes, whereas the specification says it should still be 4-bytes, even for PSB format - it's one of the few sections that doesn't write it's size as 8-bytes for PSB. It doesn't appear you are making the same mistake when writing out the 16-bit version of the file. The section size should also be 0 or rounded up to 16 bytes (multiple of 4). You are storing a section size of 14 (rounded to multiple of 2). The specification shows the structure should be 13 bytes, rounded up to 16 with packing. Photoshop is being lenient in letting you open this file - hence why you can resave it. The file it saves out again then corrects your errors. We won't be fixing anything our end because we are following the spec.