Jump to content

garrettm30

Members
  • Content count

    37
  • Joined

  • Last visited

About garrettm30

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I’m surprised how little discussion there has been around the forum about this. This is not exactly a workflow problem is as it is a more fundamental issue of quality of output. In cases where paragraph justification is required, InDesign and others like it will simply produce superior results in this regard than software that does not have some sort of multiline composer. I’m surprised more people haven’t requested this feature. For me, as I do plenty of justified text, often in narrower columns with nonbreaking spaces (that is, where a basic single line composer shows its weaknesses), I could not recommend taking such a step backward from what we are able to do now in InDesign. I would have thought that this kind of thing would be priority for professional layout software: naturally the first version of any software will have fewer features, but one would hope that it would do its few things well. As far as justification, it is more like Word than InDesign**. However, I can be patient with the developers in this: whereas I would think this to be a core feature when starting a new app of its kind from scratch, I suppose the reality is that Publisher is not truly starting from scratch: it is building on the foundation of Affinity Designer and perhaps to a lesser extent Affinity Photo, and clearly a multiline composer is far from a priority in those apps. With those as its foundation, I can understand that a multiline composer might not come right away. I just hope Serif understands how important it is for the quality to truly shine. Without it, I don’t think I could use Publisher for work requiring significant amounts of justification. **To be fair, Publisher does currently handle justification at least somewhat better than Word, in that it has customizable word spacing and letter-spacing, so it’s got at least part of the solution, but the gappy spacing still remains.
  2. I just stumbled onto this thread, and I am happy to see fellow Antidote users in this forum. I suspect we are a rather small minority, so I never even bothered mentioning it as a feature request. Although I don’t feel right claiming this is a “must have” feature, for my own work, I don’t know what I would do without it. I think the impetus for integration rests more with Druide than it does with Serif (although it would surely require Serif’s cooperation). On the Antidote website, they do invite this kind of feedback: They may not be interested in integrating with a beta, but once Affinity Publisher goes public, I do intend to contact them. Here’s the link for anyone interested: https://www.antidote.info/en/contact (English) https://www.antidote.info/fr/contact (French)
  3. The discussion of what to call this has been interesting to me (I’m just now catching up on the thread). I am familiar with regular expression from my experience in programming (predominantly PHP, which does use PCRE). In the last few years, I have come into the publishing world, where I noticed InDesign calls searches by regular expressions “GREP” in its Find-Replace dialog. I have known there is technically a difference, but I have not really paid attention to what it is. When naming this thread, I supposed there were many more readers familiar with InDesign than with programming, so I named the thread according to what I supposed people are familiar with. If Affinity chooses to add this feature and call it “Regular Expressions,” then perhaps that is the best and most consistent, but honestly, I’ll be glad to have it even if they choose to call it “GREP” even if slightly inaccurate, or even “Geeky Super Search.” As to flavor, sure, I would be happy with PCRE, as that is what I know. I have occasionally come across features that work in regular expressions in PHP that didn’t work in InDesign GREP—I can’t remember what it was, maybe negative lookbehind, or some such. However, I suppose that we most likely would get whichever flavor is built into the programming architecture in which the apps are written. I only know web programming, so I am guessing here, but I would think that if they use the functions provided by the programming languages they are using, then it should be a very easy thing to implement. And just for fun, here is the resource I use for building my regular expressions, both for use in InDesign and also for programming. Perhaps some of you may find it as useful as I have: https://regex101.com
  4. The text in that file has hyphens and line breaks hard coded (by that I mean actually typed as text). In the screenshot below, I made this apparent by reducing the width of the text frame and observing how the text reflowed. On the first line as visible in the screenshot, the hyphen after écono is a soft hyphen, added by Publisher's hyphenation. The hyphen and the line break on the second line (after "mi") are actually typed into the text, and they will appear no matter where the text flows. I don't know where they came from (perhaps you copied from a PDF or other source where hyphens or line breaks were already applied), but you can just delete the extra hyphens and line breaks.
  5. I think there is some misunderstanding here. It is true that Affinity is working within the standard print dialog box (which sometimes I wish Adobe would also do -- I still can't send jobs of more than 999 copies, even though I can in basic apps like Preview). BUT, they are using the application specific section. The "Range and Scale," "Document Layout" and "Bleed and Marks" are specific to Affinity Publisher. This is not dependent directly on either what macOS provides or the printer driver. Notice these comparison screen shots of the dropdown printer settings menu of Affinity Publisher, Affinity Photo,TextEdit, and Preview : In all of these screenshots, the printer I selected was the same, but the top section differs according to application. Or compare the above to this screenshot, which is Affinity Publisher printing to a Xerox (the ones above are to a Canon irADV): It is an entirely different printer, so naturally the print driver features (middle section) are different. However, the app-specific section that Affinity provides is identical. The Document Layout section and the other two are custom by Affinity. If you need more convincing, notice this print dialog box from Affinity Publisher printing to a label maker: Again, that is an entirely different print driver, but the same three options specific to Affinity are there. You can be sure that it wasn't DYMO who gave us the option to print booklets onto a roll of 1⅛ x 3½ labels, yet the option is there--because Affinity provides that option, independent of the print driver. I appreciate this thread, because it has forced me to think it through, and in the end, I think Affinity is making the right choice to work within the paradigm of the operating system. (I would be interested to know how this is handled in the Windows version.) Sure, a few of the options could be fleshed out (for example, creep in booklet mode - and what is the difference in book and booklet modes?). But those things can be added within the framework that Serif has already established in these betas, and I think working in the standard dialog box is the wise choice. InDesign's implementation tries to rewrite their own print dialog box to some extent, and despite what must have been a massive effort, it is buggy. To give just one example, with the latest drivers for our printer, I have to save as PDF or PS and then print from the lowly Preview instead of printing directly from InDesign. I must do this anytime I need both offsetting and a cover page taken from a different paper source. From InDesign, if I try to use those settings with multiple copies, it sends the job as though it were one really long document rather than multiple copies of a normal document. It takes a long time to send to the printer (like half an hour), and then when it prints, it treats it as one really long copy, with exactly one cover page and offset exactly one time. I have used these same settings in InDesign with previous drivers without this problem. But those are the kinds of things that happen when they try to go maverick. To give another bizarre example, Safari's print dialog box is also somewhat custom. Although it is styled to mostly look like the standard implementation, it does not respect Apple's own convention. Not only are the options moved around from everything else, but there is a persistent bug that I reported more than seven years ago—when I was on a different computer, different operating system, and I had a different job in fact with different needs—where it will not respect paper margin settings. To specify a margin in Safari, you have to first go to System Preferences, create a custom paper size with the desired margins, and set that paper size to the default. Thank you, Serif, for not messing with these things.
  6. I use InDesign's Print Booklet regularly for a few hundred of our publications, so I would be happy to see something more substantial in Publish. So in that sense, JDW, I get your point--I too would love to see that feature. However, I have done some testing, and I am able to get reliable booklet printing with Affinity Publisher as it is now. (It is actually one of the first things I tested, because I knew I would need to be able to print booklets.) Creating a proper booklet printing interface is probably a rather large task, especially once you have to deal with so many different printer types. I can imagine that it could be rather massive. I really don't think we could rightly expect that it should be ready for any of the version 1 releases, especially since they have a number of other essential (or as I read it so often, "show-stopper") features to implement. If Affinity Publish in its first release meets my needs otherwise but is lacking in booklet making, I would be happy to buy proper imposition software and still use Publisher for layout rather than continuing to hemorrhage money to Adobe for InDesign. Dedicated imposition software can be more capable than even InDesign's Print Booklet feature, so I might end up preferring it. Summary: I would like dedicated Print Booklet feature, but it is my opinion that it is more of a luxury than can be expected in the first version of $40-50 software.
  7. I have tested your file, and indeed it seems that the calculation for wrapping around edges needs to be tweaked. In the screenshot below, I have opened the file and replaced the text, on the the left, with a letter that descends below the baseline, and on the right, with a letter than ascends above the cap height. I have also selected all of the text to make the text lines more apparent. I see that in the top of the circle, it appears to align perfectly to the text baseline, as you can see that the tail of the p dips into the outer circle. At the right edge of the circle, it aligns perfectly with the left edge of the text bounding rectangle. And on the bottom, it appears to align perfectly with the cap height of the line of text, as you can see that the acute accent on the É is crossing into the outer circle. All of these things are probably just what need to happen to appear aligned correctly. It seams that it is the transition from each cardinal direction that it gets progressively worse until about 45°, and then it starts to get better again the closer it gets to the next cardinal direction. Or to describe it differently as though the circle were a compass, it is best aligned at north, east, and south, and worse at northeast and southeast. Perhaps that is a helpful clue to the developers to see where the problem is? Or maybe not, but that's all I've got.
  8. @imcath, it sounds like you are looking for a word processor rather than desktop publishing/layout. It's true that there is overlap in what each category can accomplish, and I think it might make for an interesting discussion about the philosophical differences between the two. For the purpose of this response, I think it is sufficient to note that the two categories are indeed different in both their market and their workflow approach. Affinity Publisher seems to be positioned to compete in the desktop publishing crowd (along with apps like InDesign, QuarkXPress, Microsoft Publisher) rather than the word processor crowd (Microsoft Word, Writer in OpenOffice). Despite the overlap in some functionality, Affinity Publisher is not positioned to compete with word processors; it isn't really in the same category as Apple Pages (not iPages), so I wouldn't hold it against them if it is not the Pages replacement you were hoping.
  9. I am able to use this and other varient spaces from the mac "Show Emoji & Symbols" menu (pictured below), but I have also requested in another thread that several of these spaces be added to the Insert menu, namely, thin space and hair space. I do use both of those.
  10. From the changelog on 1.7.0.128 I take it that these two fixes refer to my two screenshots above. The spacing as shown in my first screenshot has been resolved in 128. The second (where "body" looks like "bodv") still appears exactly as the screenshot. Note that I have "Font UI Size" set to large in the preferences; this is a Mac without retina display.
  11. I think the most promising solution is to take the "image with camtion" that you have already made and save it as a symbol. For me, they take a little getting used to, but I think there is a lot of power there.
  12. garrettm30

    Hyphenation still doesn't work

    Yes, that is the bug I described. Your video may be helpful to show the developers what I tried to describe above. There is a workaround: don’t change it by editing the style directly. Pick a paragraph of that style, and edit its minimum score from the paragraph studio. Then with that same paragraph still selected, go back to the styles, right click on the style, and “Update Style” to match that paragraph.
  13. I second that suggestion. I would use optical kerning often if that were the solution offered, but personally, I think giving us a way to manage custom kerning pairs would be the superior solution in most cases, and perhaps easier for Serif to implement.
  14. That's interesting (and I occasionally do use Greek, but never yet in Indesign for professional work). So does optical kerning solve that problem?
×