Search the Community

Perhaps this is a user error, and not a bug, but it's driving me bonkers. Help! I have a 20-page publication for a client I handle every other month, and each month they like having a new color theme. I have always handled this by creating a global spot color, and then editing that color each month so that all colors change across the document. One edit, and everything updates! This seems to work fine with everything aside from Drop Cap styles. I want the Drop Cap to refer to the theme color. I have a special Drop Cap Character style that is linked (supposedly) to the global spot color. This Drop Cap Character style is referred to in a Paragraph Style, which I apply to the first paragraph of each article, with a Next Style of the regular non-Drop Cap text. EACH MONTH I go through the agony of having to open and edit the Drop Cap color. Otherwise, for whatever reason, when I apply the Paragraph Style, it pulls the OLD spot color from the previous issue, instead of the updated Spot Color. In fact, I have to open the Character Style, select another swatch, CLOSE the style, then OPEN IT AGAIN, and select the global spot color and close the style again for it to update correctly. Nothing else seems to work. I have paragraph rules that also refer to this spot color and update just fine. I have various graphic elements at various tints that refer to this spot color and update just fine. I even have tables that refer to this spot color and update just fine. It only seems to be Drop Cap that is affected. Please let me know if I'm doing something wrong, or if this is a bug. Thanks! (I am running the Publisher Beta 1.7.0.257, though this has been an issue for months and I simply haven't bothered to report it. I'm an a 2017 MacBook Pro running OS 10.14.3.)

Windows 10 Home 1809, Publisher 1.7.0.206. I've noticed that the Drop Caps feature always seems to want to 'drop' a letter regardless of what the first character in the paragraph is. For example, in the attached image: 1) Drop cap with letter as first character is as expected; 2) 'D' has been replaced with '>' and both the '>' and 'r' are dropped; 3) Keep adding more non-letter-characters and the problem persists; 4) This is what I think it should do. I've tried clicking round the glyph browser adding different characters and sometimes it drops just the first character and sometimes it drops more. It seems like Publisher has its own opinion on what a 'letter' is and, therefore, what can be dropped. Is the feature working as expected or is this a bug? (If it is working as expected, can anyone explain (A) why I can't use non-letters as drop-'caps', or (B) how I can do what I want?) I have a clunky work-around - as seen in figure 4 - but I'd rather not have to use it if possible. This post seems to be on a related note but from a different direction: https://forum.affinity.serif.com/index.php?/topic/74084-drop-caps-feature-suggestion/