000

It would be very beneficial, if it was possible to apply a different style to each character of the drop cap feature (e.g. three dropped caps = three style selection fields). Here's a sample of what this could be useful for:

Sorry, just noticed that you can only drop one cap ... however, this has already been changed in the new 1.8 beta, so it should be available for everyone, as soon as the next update for Publisher releases. Currently you need to create one single new text frame with your drop caps (same method as described above) and pin it to the start of your paragraph. I have put a feature request in for an enhancement of the current feature, which would make life even easier:

Write every letter two (in your case three) times and use kerning to position your letters perfectly on top of each other. Below a screenshot using the free font "Romanique Initials" with two colours and a marker where you can see which value to edit for the second (and in your case third) letter -- for this sample I set it to "-880", but it may vary from font to font. Make sure to use what Affinity calls "global colours" so you can set them to overprinting if needed and also change the colour without "unfiddling" your letters manually. If you use a text style, you can also adjust the size (or even font) later on; And when you even use two (in your case three) text styles, you can apply and reapply the kerning values and colours by simply switching styles. This method works without ANY extra text frames, you can just put your text in any Frame you like and even place them in the middle of your text if you want. In combination with the drop cap feature (in you case set to three characters), that should make your life much easier.

Agree, there could be a bit more contrast ... since there are a light and a dark UI the selected buttons could just switxh (change from lightnto dark and vice versa).

Here are three screenshot I took from Publisher ... same machine, same screen settings and resolutions. I opened both (1.8 beta and 1.7.3) next to each other and as you can see, the newer interface is noticeably smaller (if you look for the 1.8.499 beta tread, you'll find that I'm not the only one having this issue).

Maybe it's just on high res screens? I have a 5K iMac and the difference is significant. I know about the font size option, the problem in my case is that is has gotten harder to quickly "aim" and click on the buttons and options. Only solution for my screen is to reduce the resolution, but when I do, my whole system gets "larger", not only the Affinity software, and I don't want that. When the Publisher beta came out last year, I took screenshots -- I'll dig them up when I'm back on my office on Monday and post them here.

Already posted this in the initial Publisher .8 beta thread: The UI (buttons and text) are roughly 20% smaller than in the .7 versions -- hope this is a bug and not intentional, because it makes the software harder to use.

Already posted this in the initial Publisher .8 beta thread: The UI (buttons and text) are roughly 20% smaller than in the .7 versions -- hope this is a bug and not intentional, because it makes the software harder to use.

Michael, make aure that you are not using a font manager, but install the fonts using the OS -- that's what fixed the problem for me (see my post above). It's a strange one, hope this gets fixed at some point (by either Serif or the font manager people).

Have a great time and a good start into 2020!

@redlik While I agree that there is still a lot of things missing that other software has and all the points you list are absolutely valid, I think "not ready for pro production" is a bit harsh -- I have just sent my first 92 page product catalogue to the printers and couldn't be happier. I cannot transfer all my work to Publisher yet, but for a lot of jobs (professional work) Publisher is suited.

It would show what pages and which frames text contain more text than fits in the frame.

Text overflow

Thanks Jon P!!!!

Publisher can actually do both: You can use container if you want, just draw up the image box (a clipping mask / clipping container) first and then place the image inside (there is a picture frame tool in the toolbar) — just when you place an image directly from a file or paste it from the clipboard, it is imported ,barebone'.

Looks like in your case the "tint" is separately from the colour (that's what I would prefer) whereas in my example the tint changes the colour -- anyways, the functionality seems to be jumbled up somehow. I keep my fingers crossed someone from Serif looks into this and it gets sorted out so that the tint works reliably the same in all three apps all the time.

Yes, possibly ... different software, different workflow. Just wanted to put in here in case it actually IS a bug, because tint is handled differently in other software and I wasn't sure. If it's by design, just close or delete this thread.

1) Open Publisher 2) set it to full-screen (macOS Catalina) 3) open large file 4) Swipe back to desktop, copy image or text 5) Swipe back to Publisher Result: Beachball shows for up to 20 seconds before Publisher can be used Note: When used on the same screen as the file source (e.g. seperate windows with Wordfile or Finder opened), Publisher behaves normally / works fast. The ,pause' only happens when it runs fullscreen and I'm swiping between screens. My guess istthat something is deleted from temporary memory when swiping between desktops / screens.

1) create two global colours 2) apply Global Colour ONE to any object 3) Use the "tint" slider to set the colour to 50% 4) Select object and apply Global Colour number TWO 5) result: Colour is applied, tint is reset to 100% Expected result: I did expect the colour to change but the tint setting to stay at 50%

1) Create a paragraph with a left indent 2) try deleting empty lines on top of this paragraph using the backspace key 3) result: before the empty lines are deleted, the paragraph indent is deleted -- see video -- paragraph_indent.mov

Good idea, Walt ... maybe one of the mods can move it?

The buttons "Update Paragraph Style" and "Update Character Style" are dangerously close to the style selection menu on the Context Toolbar -- just a simple accidental mousclick can mess up the entire document! My suggestion: Place the command "Revert to Paragraph Style" (removing all manual adjustments that were made after applying the style) in its position.

Your word in the developers ears. I'm super happy with 1.7.3 at the moment and love working with it. That said, I can hardly wait to get my grubby little mittens on new features and see what the programmers have come up during the past few months.

Hi, I have a text document with 80 pages, 3 columns and the text is set up with 8 different text styles, all lines set to "use baseline grid". When I include any flow settings into the paragraph styles (e.g. "keep header with three lines of text" or "keep info1 with previous paragraph") the software crashed, when I start editing the text and the amount of lines of text in the document changes (e.g. deleting a word and causing a paragraph length to change by one line, deleting a blanc line between paragraphs or adding a line of text somewhere) -- I guess that Publisher somewhere craps up when trying to re-calculate the whole document while maintaining the flow settings active. When I delete / deactivate all flow settings, the same document works fine. Quick edit: This bug also crashes the release version 1.7.3

You're either ahead of your time or member of a very secret beta club -- in both cases: WOW!