garrettm30

Agreed, and to that I add fixed-layout digital media as well, such as PDFs. Whether for print or for digital distribution, it still starts in layout.

I'm caught between these two contradictory opinions, as they both seem right to me in some way: I do think if the thread were to be closed as is, it would suggest to many that Serif is not interested in this feature and that they want to shut off any further discussion. Of course that is not true, as we who have been through this thread for a long time can tell from the bits and pieces that Serif reps have told us. My point, however, is that the many people who are new or generally less engaged in the forum may not have come across those posts yet (in fact, many recent posts in this thread seem to indicate that to be the case). To avoid that, if this thread is to locked, I would recommend to Serif to make some kind of comment as a last post that Serif has definite plans to add footnotes in the not too distant future, or even that they have already begun work on it—if indeed that is the case (as I have assumed from some of the comments I have read). Even if the thread is not closed, it would be helpful to have Serif post one of a pinned posts (accepted answer?) that is at the top of every page of the thread so that newcomers won't have to dig past all the repetition to find an actual answer. I feel like there was one until recenty, but it is quite possible that I remember that happening on a different post, such as data merge.

I think it was never intended to have them in Publisher, and if I remember correctly, it was an error that they once were available in a Publisher beta. So from that perspective, they were never a Publisher feature that has since been removed. That said, I think it is still valid to raise the question whether they should be intentionally included in Publisher.

The other languages each should follow a consistent approach given their own language, but consistency is key. Generally, fixing these issues in the English strings should have nothing to do with the other languages, although, depending on how the localisation environment is done, it could mean that all of the other languages would have some work to do at repeating their existing translations. I only have experience at web localization, but I know that in some implementations a simple comma addition in the original (English) string means that the software sees a "new" string for all of the other languages to translate. But that is still fairly minor, and fixing a particular translation in this way should not even need to take other languages into consideration.

It got even more expensive as of yesterday. $199 US just for an iterative upgrade from last year's version!

We have already said everything about footnotes that I think we can, so might as well make this thread interesting in a different way. Time to grab some popcorn! Jokes aside, I would like to suggest that I didn't think that Peter's post was particularly aggressive. I think his response was a little more pointed than the average post, but I got the same feeling about the post to which he was responding. For the sake of not getting this thread shut down by the moderators, might I suggest that we assume none of these posts were intended in a particularly agressive or hateful way, even though it might come across to some of us as such? Sometimes words in text are more open to misinterpretation. Or by speakers of different languages. Or…

I think what you are talking about is not what the English widows and orphans refers to, so that might be where some of the confusion lies. An orphan is a single line of a paragraph as the last line of a page, and a widow is the last line of a paragraph at the top of a new page. The Paragraph Studio controls for these things causes an earlier page break than otherwise necessary in order to insure that there are at least two lines of each paragraph on each page. Put it another way, widow and orphan control in English refers to managing page breaks, not line breaks. So do I understand you to be asking about the latter? If so, there is no setting that would do it in Publisher, but you can prevent line breaks at certain places by inserting a nonbreaking space instead of a regular space. I would even suggest find/replace by regular expression. I do not know the rules of your language, but here is a sample where I have assumed that all words of a single letter should not start a new line. (Be sure to set up the find/replace in "regular expression" mode.) Find: ([[:alpha:]])\b (There is a space at the start of that string, so be sure to select it as well as the rest.) Replace: $1 (There is a nonbreaking space at the start of that string, so be sure to select it also. I think your browser may copy it as a regular space as mine does, so just be sure you have a nonbreaking space as the space character before the $.) That gives the idea. If you need help to alter the rules of that search, please let us know. Or if it is not clear (as may well be the case), then give me a sample document and explain the rules of which words should not break in your language, and I will try to demonstrate with a short video.

Your are right, there are others who are helpful in this forum. But if there were an award for most helpful Serif forum member, I would nominate you. I feel like I should contribute to the main subject of this thread, and in fact, I do feel like commenting on this: I have never really tried the light interface, but wow, that really is hard to see. It is not nearly so clear as in the dark interface, and I agree that something should be done. After a little experimenting, it looks like—on Mac at least—the color of that faint indicator is something like 50% of the system highlight color. In my case, my system (Mac preferences, not Affinity) highlight color is purple, and this is what I see: I am not certain if such a thing is similar in Windows, as you appear to be using. But I notice that your highlight color is already rather light, and a semi-transparent version of that on top of the light interface is indeed hard to see. Sometimes I have had a hard time knowing where to point to get the indicator to go where I think it should, but I have not had trouble at least seeing it, so I was never in doubt as to where the object/layer would be when I let go of the mouse. Maybe Serif should consider a different way to display that indicator. I would suggest using the same highlighting color as it is now, but using a more definite border with plenty of contrast (adapted for dark and light interface). On my Mac, that border is a dark purple even on light interface and a light purple on the dark interface, but on the Windows screenshot, it appears to be white, which is not so helpful on a light interface.

That's just the regular nbsp, not a fixed-width, and it has the same justification stretching as a regular space. I cannot find a unicode character that mimics InDesign's "Nonbreaking Space (Fixed Width)" character. When I copy that character from InDesign and paste it into a unicode identifier, it identifies it as "U+202F : NARROW NO-BREAK SPACE [NNBSP]". Publisher renders it narrow, as I think was the intention.

Interesting idea. It would seem that the results are the same, at least in this sample scenario: I think in that case, it is just a convenience of entering one special space versus seven special spaces and one normal one. As I indicated, this is all new to me, so I really have no experience with it. I was only answering GarryP about the difference in what he demonstrated versus what the original poster is looking for. One thing I didn't realize is that flush space does not appear to be a standard unicode character, and so cross-app compatibility could be a problem. But then, I can't find the non-breaking fixed-width space in unicode either. When I copy the above text into Publisher, neither the flush text nor the fixed-width space behave as expected. The flush space is pasted as an em quad, and the fixed-width is pasted as a narrow non-breaking space. So the question is how one can achieve this in Publisher? (Maybe a third space or a quarter space instead of a fixed-width non-breaking space is close enough?) On the other hand, if InDesign is repurposing characters to be used in a different way than intended, I do not think that is a good idea.

I think this is the thread you are looking for: It is recommended to join an existing thread when there is one for the feature you desire. It helps keep the conversation from being fragmented. And I suspect that one very popular thread that keeps coming up is probably is more noticeable than a bunch of one- or two-post threads that crop up from time to time and then fall off the first page, forever forgotten.

@GarryP There is a linked article in the original post that explains what flush spaces can be used for (and it is new to me, so thanks @James Rodriguez) This image (which I got from said linked article) demonstrates the difference very clearly: In the first example, every space is given equal value. In the second, the regular spaces have normal width, while the flush spaces are uniformly expanded until the line is filled.

I feel like option 2 would be much more helpful, because it gives you the ability to make design tweaks in either the existing document or in new documents that are styled differently. I think saving formatting without saving character styles would be atypical of what the user might expect.

It is an acknowledged bug. Using dark mode is is the current workaround.

I do quite a lot of printing of postage labels, but I never would have thought to pass them through a layout program like Publisher. That sounds like a lot of extra work (perhaps only a little per label, but it adds up if you have to do it for every label). I assume you must have some fancy design into which you are putting the label, for that "extra mile" look? Anyway, this problem is indeed being addressed, and you can test it out for yourself if you download the latest 1.9 betas.

I'm not sure where we're going with talking about this Google stuff on iOS. The original comment pertained to Google software preinstalled by Apple on iOS, to which the question was raised, Which software? As far as I can tell, there has been no Google software preinstalled by Apple for years. Yes, YouTube and Maps apps used to be included (even those were developed by Apple), but now for many years there has been no YouTube app installed by default, and the Maps app switched over Apple's own backend with iOS 6. Of course, its early weaknesses are infamous, but I have been using Maps (by Apple) exclusively for several years now, and I am very pleased with it. We each can have our own preferences as to which apps we like better, and every app has room for improvement, but I don't see how your disparaging Apple Maps helps contribute to our Affinity-focused discussion. And you can hate on the browser, but the Chrome-Safari relationship has been a give and take. Apple started WebKit ultimately to break Microsoft's Internet Explorer dominance that existed at the time, and as their goal was not their own browser dominance, they released it as open source, and other browsers including Google Chrome made use of it to power their browsers (in Google's case, until they forked it and renamed their version Blink). Back in the day when the Maps app on iOS was using Google, the Chrome app on Android was powered by WebKit by Apple. In the end, Apple achieved their goal: the WebKit framework and its Google derivative Blink now powers most browsers, the IE dominance has been broken, and the web-developer world is better for it. (WebKit itself was a fork of KHTML, so we could go in circles about who is indebted to whom, but it seems to me that we should just recognized that advances in development are a mutual affair, both in origins and resulting benefits, and leave it at that. I think both Apple and Google together have made the web world a better place. I also think each of them has made the world worse in other respects, but that is a different discussion.)

Literally "estimated time of arrival," which is usually in the context of travel, but it is often used less literally for other circumstances. Here, the meaning is that Gabe cannot provide any estimated time for how soon a fix may be released.

@GarryP I believe I misread the intention of your post to which I replied, so now I see that we are in agreement and that my own post was not really so helpful. I apologize.

Narrowing down to the specific page would already be a significant improvement and save a lot of time at identifying the problem.

Although it is not the same functionality, in Publisher you can find/replace text by format including color, and that might well serve the purpose for the kinds of things that Publisher is needed for. For objects, Designer is the better choice, which of course is available via the persona in Publisher.

Welcome to the forum. The idea for a poll is not bad, but in this case I think unnecessary at this point. I understand you are new to the forum, so you probably did not yet know that Serif has already recognized that footnotes are hotly desired and indicated that they plan to add them, and more recent discussions from their representatives seems to indicate that development has already begun, though we won't see anything about it until Serif is satisfied that it is ready to start showing up in betas. Therefore, I don't think a poll will make any difference at convincing Serif to do something they are already convinced to do and evidently have started to do. And if they still needed convincing, this long thread of many comments (which Serif pinned to the top, take note) probably is more effective than a poll. Of course, there is no harm in a poll, so have fun with it.

It does? Off the top of my head, the only Google anything preloaded on iOS that I can think of is that Google is the default search engine choice (and Google pays Apple the big bucks to keep it that way), and that is not really just a setting rather than a product preloaded. I may be forgetting something, but I really can't think of any Google product that is included by default in iOS. Before iOS 6 (released 8 years ago), they did come preloaded with a YouTube app and a Maps app that used Google Maps. The YouTube app is long gone, and Maps has been powered by Apple's own system.

More like one quarter of the world, from what I can tell (example)—still a very signficant number, but let's keep it real.

There is no solution for RTL in Affinity at the present. The presence of a certain program file that Dominik discovered may be a hint that Serif has been working on or investigating RTL support, but I am not sure even that much can be safely assumed.

I do agree with this short summary. I think collaboration would be a good candidate to “take it to the next level,” after some of the more basic or “essential” (in quotes because what is essential can be rather subjective) are firmly in place.