Colin_Fredericks

Update: Installing the static fonts did indeed work. @AlfredThank you for the fix. Overall this was incredibly frustrating. Seriously, I probably spent 8 hours over the past 3 days trying to figure this out - an entire work day wasted. I should charge companies my consulting rate before I try to document their bugs. I'd be a thousandaire.

Seriously? No warning or anything when I try to use them, they just fail? I spent hours trying to track this down over several days.

Greetings! I've run into a font rendering issue in Publisher 1.10.4. I'm on MacOS 11.6.1. Edit to add: Alfred found a workaround below. Check out the first reply if you're working with variable-width fonts. In the first attachment you can see a Google Font, Newsreader (Regular weight in this case), in both the on-screen view from Publisher and the exported PDF from that same file. The in-app display of Newsreader is so bad that I wondered if I had installed the wrong font, or if there was a more serious issue. The kerning is different, and even the shape of some of the letters is different (look at where the arcs on the "m" connect, or even the shape of the "o"). I find it hard to even work with on screen - it's genuinely difficult for me to read it. Steps to duplicate are installing Newsreader, typing anything into any document in that font, and exporting a PDF for comparison. The screenshot is from a new file. In further bad news, I seem to have found another bug with this particular font while testing and reporting this one, which is that setting the font to "Bold" or "Light" or what-have-you and exporting a PDF again does not get you Bold in the PDF. The PDF retains Medium-weight. Changing the font weight works on-screen but not in export. See second attachment. This makes it really unusable. Any help would be appreciated. P.S.: I have already reported the issue to Google Fonts, and they of course told me to report it here, because getting any kind of help with modern applications is a never-ending-game of "go ask your mother."

I regret to inform you that this does not work. Both "Paste" and "Paste in place" give me unformatted text, and all other Paste-related menu options are greyed out. As for Wonderings and Petar, sorry, no. Not sure why you felt the need to post in this thread at all if what you're here for is to tell people not to use the product.

Yet another +1 for IDML export. I am currently, as in right now, today, in the position of having created a file in Affinity Publisher and needing to entirely rebuild it in InDesign for a colleague. It's not a complex file. Honestly, all I need are the paragraph styles and character styles. But there's just no way to do it right now, which means creating things in Affinity has become a pain point for my operation.

Explaining group matching - feel free to skip if you know this. "Group matching" is when you surround something with parentheses in a regular expression. It captures the matched group so you can put it back in later ("group replacement"). For example, if I wanted to change <strong class="example">emphasis</strong> to <em class="example">emphasis</em>, and also change <strong style="font-size:large;">emphasis</strong> to <em style="font-size:large;">emphasis</em> at the same time, I could do this: Find: <strong(.*?)>(.*?)</strong> Replace: <em$1>$2</em> and it'll replace the <strong> tags with <em> tags and keep any of the attributes. The first group is $1, the second group is $2, etc. The (.*?) group says "any character, zero or more of them, don't get greedy." (And yes, I know, using regex with HTML is counter-indicated, it's just the first example that came to mind.) In this particular case: If you run that kind of replacement when there are lines in the "Find and Replace" studio panel that do not highlight their corresponding places in the text, you get the sorts of results that you see in the sample file. The groups that are replaced do not match up with the groups that are found, and I haven't found a reliable pattern to it yet (though there probably is one). The non-greedy qualifier issue: Now, in the example I gave above, the question mark works just fine. Try adding it to the case in the sample file, however, and the match becomes individual letters instead of words. Try it with .*? instead to see it match the spaces between letters (which I'm not sure should ever be matched by any regular expression). Not space characters " ", but the boundaries between one character and the next. I only found this because I routinely type (.+?) instead of (.+) by muscle memory to avoid matching, say, everything between two different sets of <strong> tags instead of just the contents of the tags.

I ran into a nasty bug with find-and-replace and regular expressions recently, and wanted to make sure folks were aware of it. The issues are... What's shown in the find-and-replace studio panel does not necessarily line up with what is actually matched by the expression. (You can tell by clicking on the matches and seeing what highlights and what doesn't.) If you run the replacement with group replacement and any "missing" matches, what you get out is unpredictable. I've uploaded a test file that demonstrates the issue. My machine is running MacOS 10.15.7. I'm on Publisher 1.9.1. As a separate issue, Some matching characters don't work as expected. For instance, the non-greedy qualifier "?" seems to pick out individual letters rather than grabbing whole chunks of text. RegEx_find_replace_bug.afpub

I switched from InDesign to Publisher for a few reasons: Price. I can buy Publisher outright for what it costs me to rent InDesign for two months. Good feature set. It's not everything I could do with InDesign, but it's about 90% of what I used. The only real losses that I've noticed were object styles, book files, and cross-references. I'm just done with supporting Adobe. I use Affinity Photo, but I use Pixelmator more. I use Designer, but I never owned Illustrator in the first place, so it was more of a "complete the set" purchase.

I made a test file (attached). It only took about 5 minutes. It's 462 pages of Lorem Ipsum, on Letter-sized paper, 2-column layout, justified text, Garamond No8 font. This is longer than the books I normally make, but with much simpler layout - no images, no drop caps, no tables, only one font, etc. (I normally make 200-250 page roleplaying games.) It is indeed noticeably slow. Typing takes quite a while to show up. Typing "Typing here is slow" on the final page takes 15 full seconds to show up after I'm done with the sentence. On the first page, I can type "Typing here is not so bad" and it shows up immediately. The farther down the document I go, the worse it gets (which is the reverse of what I would have expected). Interestingly, moving around something that's word-wrapped is pretty quick regardless of where you're doing it. This is in Affinity Publisher 1.7.3, most up-to-date public version, on MacOS 10.15.1 running on a MacBook Pro 2.9 GHz Dual-Core Intel Core i7 with 8 GB of 1600 MHz DDR3 RAM. I know, it's not the version you're discussing, but hopefully this will help you test anyway. Can I recommend adding a feature for book files? PublisherLongBookTest.afpub

Ohhhhh oh that's not better. So what's happening is that, like folks said, the "Find and Replace" box is hiding in the left panel. If that panel is collapsed, hitting command-F or using the menu item does not open it in any way. Typing after pressing command-F just puts text into my document (or rapidly switches tools) rather than doing findy things. If I remove the Find & Replace studio... thing... pane? Let's call it a pane. If I remove that pane, command-F brings it up, but if it's collapsed, command-F doesn't change its status. Hitting "Reset Studio" did fix this, but not for long. Rearranging the studio so it's all on the right-hand side, and collapsing the Find & Replace tab, puts me back in the original situation. This is a problem because I don't have the screen real estate to keep that open all the time. I can at least get to it now (thanks for the suggestions everyone!) but it's definitely still a bug.

Yeah, just got that. Turns out .249 has the same issue.

Huh. And now that I read the forum, another potential bug: Version 1.7.0.238 seems to think that it is the most recent version. When I ask it to check for updates, it says I'm up to date with the most recent version, while .249 seems to be the actual most recent.

Original post title: Find command doesn't work To replicate: Create new file and insert some text, or open an existing file. Press command-F. The "Text" menu flashes briefly, but nothing happens. No Find dialog appears. Version: 1.7.0.238, downloaded today. MacOS 10.14.3. Thanks!

Awesome, thanks!

I just get the image without the enclosing group. There are still a bajillion handles when I edit its wrap outline. @MEB seems to be correct - re-exporting the PNG with transparency turned off is a workaround for this bug.