Jump to content

fde101

Members
  • Content count

    2,455
  • Joined

  • Last visited

Everything posted by fde101

  1. I can't believe I am jumping into this discussion on this forum; as @MEB pointed out this really is NOT the place for this, but here goes... In the Spanish language, all nouns are either male or female - there are NO gender-neutral nouns. The rule is that when the gender is unknown or mixed (like a group of both men and women), the nouns always default to the male version of the noun. That is considered part of the usage of the language, and is not in any way a slight toward women - it is simply the way the language works. Gender neutrality is a practical impossibility in some languages. In the English language, we have a mixture of both gender-neutral and gender-specific nouns and pronouns. Historically it has generally been the case that we would often treat the gender-specific ones much as in Spanish - if there was a mixed group or unknown gender, we would default to the male noun or pronoun to refer to the group. Once in a while we might use the female pronoun to refer to someone of unknown gender, though this historically would have been more rare. For many of us, we still "default" to a gender when unknown. This is not an attempt to slight either gender, it is not sexist, it is simply a function of the way our language works - still works - as many of us still use the language in a more traditional way and are not concerned about the "political correctness" garbage that is bogging down the supposedly "modern" generation. If someone is overly sensitive to this, they need to grow up. Again, this is NOT the place for this discussion, so I will drop off the topic at this point, but this whole thing didn't even exist until @robinp turned it into something it otherwise would not have been; that this is somehow even a discussion is ridiculous and someone needed to say as much. Can a moderator split these posts into a separate thread so as to de-pollute this one and get it back on topic? I for one would rather not need to wade through all of this while trying to look at the much more useful feature request and related discussion, and I'm sure the developers would probably just as soon keep this on topic given that they were already having trouble plowing through the on-topic posts because of how much information they had accumulated...
  2. Be aware that the Affinity apps do not play nice with NAS or other remote storage. I wouldn't expect it to be an issue with linked image files and such but the actual Affinity documents should be kept local while working on them. Using NAS / DropBox / etc. to transfer files which are not actively open in the applications should be fine, but before someone tries to open them, they should make a local copy, then close that copy and copy it back to the remote storage later on. Serif has indicated this is something they are working to improve, but currently trying to work with documents directly which are on remote storage can lead to strange behaviors and even data loss or corruption. Why not?
  3. Currently, only bitmap fills are supported, not vector ones. Support for vector patterns has been requested in a number of other threads. You can set a bitmap fill on an object using the Fill tool, by setting the "Type" to "Bitmap" then navigating to an image file you want to use as the fill. Use the various controls that are presented to adjust to taste. Once you are happy with the fill, go to the Swatches panel, navigate to (or create) the palette you wish to have the swatch on, and click the "Add Current Fill to Palette" button. You can then use the generated swatches to apply the fill to other objects as needed. (Note: Document palettes are saved with the document and are only visible in that document, but will follow the document if it is opened on a different computer; Application palettes are saved to the computer and are available in all documents opened on that computer, but do not follow the document to other computers). Note that these fills can also be applied to the stroke of an object, they are not limited to the fill.
  4. Maybe the still-little-known-about-it future DAM product could generate a contact sheet from an album of Photos, as a Publisher document?
  5. Serif does not normally comment on feature requests and almost never discusses the timing of when new features will be released. The initial release of Publisher is focused primary on layout for print, due to development time constraints. It is already expected that support for other document formats such as ePub will be added later. Personally I would be surprised if DOCX export ever made it into Publisher, though I've been surprised before.
  6. This is how I could see tags working: Add a "Layer Tags" panel. Layer tags are named, in a flat namespace (no hierarchy needed), and global to the entire document (independent of spread or artboard). Any given layer can have one or more tags associated with it. A layer which has one or more tags associated with it would show a tag icon in the Layers panel, and the tag icon would be a different color when that tag is selected in the Layer Tags panel, to help identify which layers are associated with a given tag. Clicking on the tag icon in the Layers panel would select the tag(s) that layer belongs to in the Layer Tags panel. The Layer Tags panel would have buttons underneath the list of tags to "Create Tag from Selection", "Add Tag(s) to Selected Layers", "Remove Tag(s) from Selected Layers", "Delete Tag(s)", and "Delete Tag(s) and the Layers Tagged With Them", etc... maybe that last one should be in a context menu or something instead as it is relatively dangerous. Next to each tag within the list in the Layer Tags panel would be three icons: one would select all layers in the current spread or artboard which are tagged with that tag, one would be a visibility toggle for the tag (eye icon), and one would be a lock toggle for the tag. A layer which is tagged would be visible if it meets the existing visibility requirements AND at least one of its tags is set to visible. A layer which is tagged would be locked if the current locking rules would indicate it is locked OR at least one of its tags is set to locked. Build on this by adding tags to the export persona (the way layers can be used there now), etc. Note that this is not a complete replacement for the concept of global layers. Global layers would impose front-to-back ordering of their contents and force a structure to the document as a layer could only be a member of one global layer at a time, while multiple tags could apply to a given layer and the layers having those tags could be all over the place in terms of z-order. Strange bonus idea: adding adjustment layers to tags. These adjustments would be applied to each layer having that tag, across the entire document. Not sure if this would be practical or not, or even genuinely useful, but it is a potentially interesting thought so I'm adding it here anyway.
  7. Thanks, added a comment to that effect.
  8. To further clarify, that outline shows that the object has been added to the list of snapping candidates and that as you are moving objects around with snapping enabled they will snap to that object. This method of handling snapping reduces the workload on the program in determining what things can snap to, as if you had it checking thousands of objects every time the mouse moved performance would obviously suffer somewhat (not to mention you would be snapping to every little detail on the page, which could be rather annoying).
  9. This is because those file types are currently always embedded even when configured as linked. That is something the Affinity team has indicated they still intend to improve on in some future version.
  10. Interesting... probably a matter of a difference in how the compressed data is stored as the numbers presented in that thread are not wildly out of bounds. Still, the small (percentage) inflation in size is not as big of a problem for me as the added requirement to juggle the separate files so I still prefer embedded for most of my projects.
  11. fde101

    Fonts

    Yes, there are a lot of them on Google Fonts, but be a bit careful as there are actually several licenses used for the fonts there, and a few of them have requirements that don't really even make sense in the context of a font, but which may be interpreted to require that a copy of the license be bundled with whatever document has the font embedded in it, or other such things.
  12. On the topic of a "primary text frame", just a comment that QuarkXPress has a similar feature (they call it an "automatic text box"). On the topic of spanning text across columns, there are already other threads requesting this.
  13. fde101

    Publisher Workbook?

    Designer and Photo had both been around for a while when their workbooks were introduced. Publisher is still very new and probably needs to grow a bit more before it stabilizes enough to warrant the effort of producing a book like that.
  14. Publisher does have the options to link images and manage them as linked. 99% of the time I prefer embedded images for my projects, but that's because I have a tendency to create project-specific images, add them to the document, then delete the original file. I figure that keeping them embedded probably uses about the same amount of total disk space as having them sitting next to the document file, but gives me one file to keep track of instead of dozens or hundreds. I actually damaged some of my QXP documents when I first started working with it because I didn't realize the files were being linked and deleted them thinking they were in the document and I no longer needed those external copies... oops. For a project in which the same image(s) would be re-used across documents, I would obviously want to work out an approach to linking those files.
  15. I would suggest further generalizing the "selection sets" idea as "tagged layers" - in which layers could have tags added to them in much the same manner as what is described here as a "selection set". These could be used for selections as described here, but could also be useful for indicating what to export, etc... adding the ability to control visibility at the tag level could potentially make this an interesting alternative to the whole "global layers" concept as well (not a replacement for global layers - should still have those - but as another option for some use cases).
  16. Just in case you were not aware, while the Affinity apps do not currently offer a tool for making these adjustments interactively on the object itself (and I agree this would be a nice addition), you can often get a similar effect by using the "Pressure" popup in the Stroke panel.
  17. In the interim, try periodically doing a "Save As" to save a new copy of the file, to see if it is smaller. Due to the nature of how the Affinity file format is handled, that can sometimes result in a smaller file. You might also consider leveraging filesystem-level compression: Mac - https://developercoach.com/file-system-compression-in-hfs-space-savings-and-performance-gain/ Windoze - https://www.howtogeek.com/133264/how-to-use-ntfs-compression-and-when-you-might-want-to/
  18. This. You could also consider moving the studio panels to the left side of the screen instead of the right, or making the toolbar two or more icons wide (you can do this with Customize Tools), which also causes color selectors to appear on the toolbar on the left, further reducing the need for a trip to the right side of the screen.
  19. Off the top of my head - if the panel was previously opened on an external monitor that is no longer attached or is powered off, could it be opening on that other monitor, where it is not visible? Wondering if opening the panels should be animated in some way to make it more obvious where they are showing up - maybe make the panel's tab pulse/glow for a few seconds immediately after it is opened?
  20. 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.
  21. Assuming you are getting this in the beta version, you just did
  22. fde101

    Data merge

    There is actually a mailmerge package for LaTeX: https://ctan.org/pkg/mailmerge
  23. 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.
  24. 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.
  25. 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.
×

Important Information

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.