Jump to content

fde101

Members
  • Posts

    4,196
  • Joined

  • Last visited

Everything posted by fde101

  1. Left-to-right text is already supported (the only kind that is at the moment, in fact)?
  2. Inkscape has a vector bucket fill tool. VectorStyler has a shape builder tool which can accomplish something similar, but with some caveats. Indications are that the developer plans on adding a bucket fill feature at some point in the future.
  3. If I want to make presentations, I use presentation software. If I want to make videos, I use video software.
  4. A workaround for this: instead of copying the text, create a character style from it. Then apply that character style to the other part of the text.
  5. To my knowledge Serif has never indicated that they will ever implement this, so constantly begging for a timeframe is kind of pointless as it may never happen at all. Furthermore, this is a duplicate thread now many times over, and if I were Serif having to wade through all of these duplicates, I might be inclined to implement a policy of reducing the priority of any feature request for every duplicate thread that is created for that request, particularly as it violates the forum guidelines. In fact, according to those guidelines, this thread should technically be deleted... https://forum.affinity.serif.com/index.php?/forum/52-feature-requests-suggestions/ (emphasis mine) Also, you are clearly aware of those other threads, so you have no excuse for having duplicated them:
  6. If you think about it, each "frame" of animation is basically a page in a multi-page document, which has the pages flipped automatically every X amount of time. As Serif seems intent on keeping support for adding multiple pages limited to Publisher at the moment, this feature might actually work better in the context of Publisher, by adding a checkbox when exporting a GIF causing each page to be treated as a separate frame of an animation (along with an option to specify the frame rate for playback). You would create a document with the required number of pages, then could switch to the Photo persona (assuming you also own Photo) to use the relevant tools to do the editing of the individual frames... Motion JPEG could then be handled in the same manner.
  7. Both the .ico format (Windows) and .icns format (Mac) are designed to hold multiple versions of raster icons at different resolutions. In other words, I might have the same icon at 16x16, 32x32, 48x48 and 128x128 together in one file. As these icons would generally need to be maintained as a unit but still be optimized for each individual resolution, I would argue that a dedicated tool is most appropriate for working with these formats. Using a program like Designer to manage icons is more appropriate for vector icon formats, and for icons which will only be exported at a single resolution.
  8. In that case you are looking for a product with a specific feature. This does not mean that products which do not have that feature do not qualify as professional or even semi-professional Desktop Publishing applications, and the context of my comment was in terms of a site that was generically reviewing applications of that nature, but disqualifying applications in such a way that made it sound like applications missing that feature were not professional DTP apps. This is not the case, as *most* professional DTP apps historically have NOT supported templates, at least not those that I've seen. If templates are required for you to get your work done, then you have a requirement beyond the application being a professional DTP app. I am not disqualifying that individual users may have non-standard or atypical requirements which some programs will support and others will not, but the way that particular site treats a feature like this as if it were essential to the nature of the application calls the legitimacy of the site into question. If the site had listed the review as being a review of desktop publishing applications that offer support for templates, that would be a different matter - they would be narrowing the field to a subset of desktop publishing applications which might be more suitable for some specific purpose or subset of users - but that is not what they were claiming.
  9. There are several ways to look at this. Consider that checkboxes in general appear to the left of their labels. This means that we see whether or not a thing is turned on, before we know what the thing is, when reading from left to right. From that perspective, checkboxes in general violate your "principles of good UI design" yet how quickly would people start complaining if some company randomly decided to place them to the right side of their labels when every other app on the platform places them on the left? Why should they be on the right when they appear in a list, when they are on the left when they are not in a list? In what way is that consistent, and if it is not, then in what way does making this inconsistent manage to fit with the "principles of good UI design"? Note that I am NOT arguing that the checkboxes *should* be moved to the left - again, I personally don't care which side they are on - I'm simply pointing out that there are different opinions about what constitutes "good UI design" and that the principles you are advocating are not 100% in keeping with convention, which leaves some room for interpretation about which side they should really be on. I would not be opposed to that either, but I do feel like this is one thing that we could also simply chalk up to learning curve. If you want to live in the USA, learn to sit on the left side of a car to drive (unless you work for the post office...). If you want to hide layers in the Affinity products, look for the checkboxes on the right.
  10. I suspect that many of those users are likely coming from the photo/illustration app world and leveraging the low cost of Publisher to get their feet wet in the DTP world, rather than coming from other DTP apps such as InDesign or QuarkXPress where the *only* layers they offer are what we are calling "global" layers here.
  11. This would be a good argument for keeping the collapse/expand triangles and the thumbnails on the left (for a left-to-right reading order), not the visibility toggles. Of course, they already are on the left... I also agree that horizontal scrolling would be a good addition to the Layers panel, but I would point out that the checkboxes can stay locked in place on the right just as easily as on the left. We are more accustomed to seeing checkboxes on the left side of a list - if you have pull-down menu items which can be checked, the checkmarks show up on the left of the item name - personally, I don't really care if they are on the left or the right, as I rarely bother using them, but I do think there are valid arguments to be made in both "directions".
  12. https://forum.affinity.serif.com/index.php?/forum/53-feedback-for-affinity-designer-on-desktop/
  13. Wait, you mean... they do?!?!?!? 😇 I just pulled up the CTAN site and believe it or not they seem to be using a lot more icons than I remember them using last time I visited it. Given the nature of the site (and of TeX itself) the site seems reasonably appropriate to me. The TeX system can still be used quite effectively on a lot of older computer platforms which might not handle "modern" web browser standards particularly well, so keeping the site reasonably simple for such systems to parse may very well factor into the design...
  14. Most people access web sites using the TCP/IP protocols, which were developed in the 70's, so a web site from the 90's is actually quite recent considering what you are going through in order to access it. Good choice. It is already a great program, just one which is not currently well-suited to your particular use case. Not in *all* other respects - no support for RTL or vertical languages, no global layers, questionable practices regarding the handling of global and spot colors, inadequate cross-reference support, virtually no interactive features (other than hyperlinks), no support for spreads of more than two pages, no support for custom slug areas (just a few pre-defined things that can be turned on or off), no support for variable or color fonts, ... ... ... Some users are much more heavily impacted by one or more of those things than by the lack of footnotes and endnotes.
  15. Is there some reason you can't just do the scaling at print time by setting the "Fit Type" to "Fit to Printable"? Have you tried using GraphicConverter (if you are on the Mac) instead for things like this? While Affinity Photo is not likely the best choice for bulk printing of lots of photos like this... File -> New Batch Job Add Files Save into (destination folder) Save as (format) - enter "40cm" and "60cm" for size OK From there, if you are on a Mac and used a compatible file format, you can navigate to the destination folder in the Finder, select all, right click -> Open With -> Preview, and File -> Print. I would imagine there is some similar capability you could leverage on the other platform. Alternatively, if you happen to have Publisher as well... Create a new document with the correct page size and the same number of pages as you have images Add the required picture frame to the document's master page and in its properties (on the context toolbar) choose the appropriate scaling option (one on each side if using facing pages) File -> Place, navigate to and select the images, then place them in the frames on the pages File -> Print No need to scale the images - the frames will take care of it
  16. Yes, if I use that tool in Inkscape, it works by adding a new object which is the shape of the filled area, and setting its fill color to match. If that shape were then cut out of the original, would that not in effect give you a shape builder tool? This is essentially a variation of the shape builder, which adds the area as a new shape on top instead of breaking the old one, and which sets the fill color in the same operation... so to implement this wouldn't be all that different from implementing the shape builder?
  17. This appears to be a duplicate of those threads which are asking for a "Shape Builder" tool.
  18. This appears to be a bug rather than a feature request. The actual gradient tool (found amongst the tools along the left side of the window unless you moved/customized it) allows you to directly manipulate the colors of the points along the gradient using the Color and Swatches panels, and when doing so the opacity is maintained when changing the color. It is only the popup gradient editor thing that exhibits this strange behavior. EDIT: sorry, this is Designer - I was looking at Photo when I wrote this. The "gradient tool" in Photo is called the "fill tool" in Designer and Publisher.
  19. Why would the other shapes not be suitable for use as guides? Why could the spiral shape not be included as part of a design? One thought about how this might be handled would be that whenever Serif gets around to implementing "global layers" (as discussed more in the context of Publisher), they could allow such a layer to be set as a "guide layer" so that all shapes on that layer would immediately become guides. Rather then "special case" shapes like this is suggesting, this would enable any vector object to be used as a guide simply by placing it on that layer (rectangle guide, star guide, text guide, cat guide...), or to be part of the design itself simply by keeping it in a different layer.
  20. No, those are not global colors in the sense that is being requested here. If you edit a global color on a swatch palette, every object in the document which uses that global color is updated immediately to use the new color which was set. Global colors are only supported in Document-level swatch palettes, and for good reasons, which have been discussed previously here on the forum. What is being requested here is basically, if the document has global colors A, B and C, then allow me to save schemes X, Y and Z, each of which may have different colors for each of A, B and C, so that when I switch to scheme Y, every object in the document which uses one of those global colors is immediately updated to match the selected scheme.
  21. Regardless, if you don't want to pay the Adobe tax, there are few other options right now. Personally if i had to create a formal or even semi-formal document such as a thesis which was long enough to have even 200 footnotes I wouldn't consider using anything other than LaTeX, but I know that way of working is not for everyone.
  22. Please consider making sure that the C-based API has the ability to plug additional scripting languages into the environment, so that those of us who hate JavaScript and its ilk could potentially create and use 3rd-party scripting language plugins.
  23. Mellel is a great word processor for this type of thing, but is not a page layout app. Right now to avoid the subscription model and get footnote/endnote support in a layout app you are basically looking at QuarkXPress or possibly one of a few lesser-known or overall less capable products. Most of the less expensive products I have looked at do not support them. Scribus is apparently adding them but they are not in a stable release yet. There is also LaTeX, of course - a bit different to work with but it can produce excellent results once you wrap your head around it.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.