Jump to content

fde101

Members
  • Content count

    2,361
  • Joined

  • Last visited

Everything posted by fde101

  1. From what I understand of it, the implied compatibility of "StudioLink" seems to be: Publisher Beta will only work with Photo Beta and/or Designer Beta Publisher (released) will only work with Photo (released) and/or Designer (released) It will usually NOT work unless the Publisher version is at least as new as the corresponding Photo and/or Designer versions The Photo or Designer version must have been run at least once outside of Publisher before Publisher is started for it to detect those programs For early 1.7.2 beta builds and earlier versions, applications must be in their original locations and have their original names. For the Mac, they must be in the Applications folder.
  2. Assuming you are getting this in the beta version, you just did
  3. fde101

    Data merge

    There is actually a mailmerge package for LaTeX: https://ctan.org/pkg/mailmerge
  4. I generally distinguish between these in that "save as" changes the open document to the one you are saving - after the "save as" you are editing the newly saved document instead of the original one - where "export" saves a copy of the document but you continue looking at the one you started with. "Export" is more like "Save a copy as..." (which some applications do offer). Different applications do seem to take different approaches in this area, though.
  5. Perhaps not, but on the other hand, if adding a "Swap command and option key modifiers" checkbox somewhere in preferences gives them the option to make life harder on themselves in exchange for bringing peace to the forums, it might still be something to consider. Note that there may be some 3rd-party options to do this on a per-application basis: https://apple.stackexchange.com/questions/13178/any-way-to-remap-keys-for-only-one-app - but this would impact shortcuts for menu items and the like too.
  6. fde101

    Tethering

    The key here being your use of the singular word "file". For tethered camera operation you are generally capturing multiple images. If this were only a matter of capturing the images, there would be no value in buying anything, the camera companies generally provide free software which supports tethering for their own cameras. The value of having this feature in a 3rd-party product is in having the incoming images (plural) organized and ready for culling, developing and editing. This fits into the model of a photography-oriented RAW development tool (such as Capture One, which is a significant player in that particular market segment) because it has the images from a session in place and ready to start working with, as a group, by the time the capture session is completed (or even while it is still underway, if you have one person capturing the images with the camera and a different person sitting at the computer working with the images). Photo is not appropriate because of the fact that it is optimized for working with one image at a time, rather than working with a collection of images as a group. My assumption is that the DAM solution that Affinity is working on will either provide RAW development capabilities internally or in some way simplify an interface to accessing them within Photo. Since the tethering capability really hinges on working with a collection of multiple photos, I still contend that this fits into the DAM model much more closely than the single-photo-at-a-time model of a program like Photo. Whether or not it turns out to be a good fit for the DAM that Serif is working on, it most definitely is NOT a good fit for Affinity Photo in its current form.
  7. fde101

    Tethering

    Photo isn't really the right application model for a tethering feature. This would be more appropriate for a DAM solution, such as the one Serif has indicated they are working on, though we don't know what that program will look like yet or when it may come to light.
  8. The major limitation being that this too needs to be repeated for each page. For an occasional merge of a very small document that might be ok... If trying to merge a dozen 50-page documents, this won't be a particularly sensible use of someone's time. I can see why lack of this feature would be a showstopper for some users to start making use of Publisher for some workflows.
  9. It is simple... simply make it possible to customize ALL shortcuts. Then the ones in conflict can be changed too.
  10. A spread consists of one or more pages, so a page might be a spread, or it might be half a spread... in the future it might be a third of a spread in some cases...
  11. This is somewhat alleviated by the status bar at the bottom of the screen. Simply remembering to look at it when starting to work on something reduces the impact of this particular problem for those who are not using it often enough to have the specific modifiers memorized. My guess would be that those who "dip in and out" would probably be less likely to have a need for this particular optimization, but if they do, then sure... it might be more obvious to them, particularly if they learned on the other product and became accustomed to it there. In a way, Adobe should actually be the easier target to go after, because people using the Adobe products are paying for them constantly while with the Corel products they are not necessarily doing that. If the larger part of the installed base of Corel users is using non-subscription licenses and not paying to upgrade every time a major version comes out, their product is already paid for so they may not be in as much of a hurry to switch to a new product, unless they see major advantages in the workflow or feature set of the product itself. In theory they already have workflow solutions that are working for them, so it might take more than a small effort to provide the kind of advantage that would push them over the edge and give them reason to pay for and learn a new program.
  12. Another thought on the grid idea is that there is almost no downside to building it up incrementally. Consider: PHASE 1 (initial implementation of feature) Always uses the bounding box of the selected object/layer Two new menu items Create Grid from Selected Object... This item pops up a box asking how many grid lines should be added in between the ones that connect to the bounding box. Upon accepting the entry, the box closes and the grid is set to match, made visible, with snapping to the grid enabled. Create Grid from Selected Object using Previous Settings This item does the same thing, but does not pop up the box asking how many lines to use, instead using the value from the last time the first item was selected. Shortcut keys can be assigned to the menu items. Whether or not there should be default shortcut keys for this is an open question. PHASE 2 (enhancing the functionality from phase 1) One new menu item, which is a toggled setting: Automatically Update Grid when Selection Changes When this is turned on, any time a selection is made, the grid is automatically updated to match the bounding box of the selection. No shortcut key by default, but one can be added by the user if desired. Disabled by default (for obvious reasons). Add a checkbox to the box that pops up when selecting the "Create Grid from Selected Object..." menu item, which reflects the state of the new menu item, for convenience. Checking this box enables the menu item, unchecking it disables it. PHASE 3 If a shape is selected which has parallel sides that are at an angle, match the slope of the grid to those sides. Adjust the produced grid to account for isometric settings. Add a "Base grid on bounding box, ignoring shape" checkbox to the "Create Grid from Selected Object..." box, turned off by default. This too should be carried over to the other (by now existing) menu items. PHASE 4 Examine the shapes to find the long part of the edge. If there is a straight (could be diagonal) side to the shape but with a part that sticks out (or in), line up the grid with the part of the shape that is longest (ignoring the small circular part that sticks out from a puzzle piece for example). This too would be disabled by the "Base grid on bounding box, ignoring shape" checkbox from phase 3. etc.
  13. From a pure usability standpoint, I agree with this completely. The issue at hand is the hesitation on the part of @Ben and thus likely the other Serif developers to devote the time into developing the "ghost" functionality that would be required for the more "discoverable" solution to become a possibility. The main reason I proposed the grid solution is that it exists now. The visibility of the grid, the ability to configure the spacing of the grid, the snapping to the grid, is all existing functionality. What would be added is basically a shortcut to very quickly configure the existing functionality, and I would expect that could be developed with minimal effort, with no changes to the core feature set of the software. With a sufficiently complete scripting interface we could probably script this solution with minimal effort. The question is if you want the "ghost" feature to go onto a waiting list with a zillion other great ideas that are competing with each other for development time, or have something that can be rapidly developed with little risk to the other features and we might be able to get it much sooner? There is no rule that they could not provide the grid feature quickly then decide to go back and implement the "ghost" feature as well at some point in the future when time permits, but if this can cover a significant portion of the use cases and we can have it that much sooner... (And apologies that I'm sure I went over 100 words with this one myself )
  14. My "grid from object" suggestion could account for this if it were expanded to bisect the generated grid. If you were creating a grid from a square with 10mm per side, you would create a grid with 5mm spacing, offset to align to the sides of the square, and simply snap to the grid line. An option could be provided to determine how many grid lines should be spaced within the object (1 for 5mm grid, 2 for 10/3mm grid, etc...) with one command to specify the spacing and another to reuse the previous specification.
  15. Here are a few other sources indicating that "prevarication" implies a lie/deception: https://www.dictionary.com/browse/prevarication https://www.vocabulary.com/dictionary/prevarication https://www.merriam-webster.com/dictionary/prevaricate I did come across another site which gave both "american" and "british" definitions of the word, but they were both the same, and carried this same implication. So are the rest of us... As to the comment about construction projects having estimates for when they will be completed... they also have fixed scope. They know what they are building when they start and can reasonably estimate when it will be complete. These software projects do not have a fixed scope: Serif is responding to requests from users by implementing features and capabilities that were not part of the original plan. The scope of the project is constantly changing, and it is impossible to estimate how long something will take when you don't know what that something is. Sure, to estimate any one feature should theoretically be possible if you know that feature is going to be the priority and all resources can be dedicated to doing that, but with different people having different "pet" requirements (such as this one) and the need to prioritize what is being worked on, different developers likely juggling multiple tasks, trying to fix bugs in addition to adding the new features, etc., the juggling act does not allow for the same kind of estimating that you might expect from a contractor working on a building project - and even they don't always meet the goals they set. Serif may very well have estimates internally on how long things will take, but as soon as they share that estimate some vital bug may be discovered or a shift in priorities may happen, and the work may be preempted in favor of something they consider to be more important. If the original work was depending on something else and that something else similarly got preempted, the effect can trickle down to many things. Still you will wind up with people complaining that they said feature X would be done five months ago... it is quite understandable that they would keep their estimates to themselves.
  16. It might be incredible, but it is also incredibly unlikely. Serif has commented several times on the numerous threads that have been started on this subject that they have no plans to introduce animation features to the Affinity lineup.
  17. I looked it up in the dictionary. If you mean something else by it, then what dictionary can I find that in - or can you provide your definition? EDIT: now that the definition was added - that does differ from the definitions I am finding for that word. All of the other sources I am finding indicate that the word implies deception. I doubt I will be the only reader who has not seen that word before, so others would be likely to draw that same conclusion if faced with that same word and trying to look it up. I still don't think that this word fits what Serif is doing, but at least the connotations don't seem to be there that I was reading into it, so for that I'll meet you half way - no project of any complexity wants to commit to a date for having something done. That would be foolish. They are not being evasive, simply realistic. Also, this is not an "open" project no matter how much the openness of the forum might suggest - this is a commercial endeavor, so there will be some things that they necessarily need to keep a lid on until they are ready to roll them out.
  18. This is a rather unusual word. I've never seen it before this thread. I tried looking it up and the definition basically means "lie" or "deception by skirting around the details" - there is no deception here, no lying going on. Yes, details are being omitted, but in order to avoid deceiving people. I think you might want to reconsider this word choice. This thread has degraded into a great example of why Serif does not normally comment on feature requests. I don't blame them.
  19. Resolve has been Linux-based for a long time because of their big 5-figure price tag control surface. The fact that they have now separated the control surface from the Linux software version is not nearly as big of a change as updating something that doesn't already run on Linux to now do so. Also, I would estimate that Linux is dwarfed compared to the other two major platforms among the customer base Serif is shooting for, compared to a smaller overall market base for a program like Resolve, where the proportional installed base for Linux is almost certainly going to be much more strongly represented. I don't disagree that it would be nice to have a Linux version of the Affinity products available, but I don't believe Resolve represents a useful comparison.
  20. You can do this when the Fill tool is selected, using the options in the context toolbar.
  21. errno 22 is EINVAL, and for flock it is documented to return that in errono if attempting to lock something that is not a file. File locking on a network share can be problematic as even with a common protocol different implementations can behave differently under various conditions, particularly when mixing protocols (though I don't think that is the case here) or connecting a client on one platform to a server on a different platform.
  22. If there is a legitimate use case that would be covered by a grid, an equally sensible feature might be to have a command to generate a grid based on a selected object. In other words, select an object, execute that command, and a grid is automatically produced such that the lines of the object is pre-snapped to the lines of the grid.
  23. This may be difficult sometimes if trying to create a regular pattern of irregularly shaped objects that still happen to fit together... puzzle pieces perhaps? I'm not sure how that relates to this request, however, as in creating something like this you would be snapping similar objects to each other, rather than to themselves.
  24. Those are not apps, and there are already app stores for all three platforms that the Affinity products are released on and it is available on those app stores. There is no reason that starter documents could not be shared on the forum if anyone is interested in doing that. If there is enough interest perhaps Serif would consider making a separate section of the forum dedicated to the sharing of user-created resources such as starter documents, templates (if/when this gets implemented), assets and the like? In fact... they already have: https://forum.affinity.serif.com/index.php?/forum/11-resources/
  25. I've seen this as well and I believe it is intentional. Photo is optimized for working on raster images in which there is typically a "background" pixel layer. As the output format of such a document will generally be a raster image as well, I suspect the vector objects are being rendered to match the underlying resolution of the document as this is a truer reflection of the state of what is hypothetically a raster document.
×