[Spacing between Table Cells in Affinity Publisher]

On 3/14/2019 at 2:27 PM, Silly Sausage said:

Now that I come to think that, you must be right.

Clearly too used to play with web publishing. If I remember correctly, Word has that functionality, but that's another thing.

Still, I still think it would be a useful feature to have - couldn't Affinity Publisher be the first designer program to have it?

Of course! No reason it has to be an exact copy of every other layout program! :-)

[[Fixed] Global Spot Color not updating in Text Style correctly when edited]

On 3/11/2019 at 4:40 PM, Old Bruce said:

I am not seeing that here. I exported the Document Pallet with global colour and then made a new document imported the Text Styles and the Document Swatches palette changed the global colour and the drop caps changed.

Yes, but that's not what I'm doing. I'm 'saving as' a file to make the new issue, then editing the spot color (which is part of the Document swatch). Which seems to update everything to the new color just fine except for the Drop Cap style. It should update all of the styles that refer to that spot color. But it doesn't for the Drop Cap. It still picks up the old spot color, even if in the settings panel is says it is using the new one.

Including screenshots here.

[Assets Panel completely broken]

I made the mistake of clicking on the minimization arrow in the Assets Panel because I didn't want to see a sub-Category. Now I cannot open any of the Asset sub-categories, and I need to access something there!

I've tried going to Window > Studio, and removing the Window from view & re-adding. I've tried resetting the studio view. I can select nothing in the Assets panel aside from the options and the dropdown to select another category.

I've also tried restarting my computer. I'm out of ideas on how to get these to open again. Help!

Running Affinity Designer Beta 1.7.0.257 on MacOS 10.14.3.

[Spacing between Table Cells in Affinity Publisher]

On 3/12/2019 at 3:17 AM, Silly Sausage said:

Thanks!

What I was really looking for was (transparent) spacing between cells, but there seems to be no such functionality.

As I need to create some tables with 20+ rows, although a bit frustrating, adding dummy cells is an OK workaround for now.

I do, however, hope that an option to manipulate the spacing between cells will be added later on.

Just an FYI, I don't know any design program that has that feature. It's a coding thing, CSS/HTML, not a design thing. Certainly not offered by InDesign. Definitely not in something more basic like Excel.

You can select a column and tell it how wide to be. When you adjust other columns, it won't affect the size of the column you've specified a width for. So simply set each of those dummy columns to your preferred width, and you're good to go.

[rearrange rows in table question]

Ah, here it is: 

 

[rearrange rows in table question]

On 2/27/2019 at 8:05 AM, ConnectCreative said:

Thank you! Finally, is there any way to rearrange the rows easily?

No, and I could have sworn I had posted that in the features request, but I'm not easily finding it now. Definitely speak up about it! Would save me some time and headache when a client wants to make an order change and I have to do a little dance to shuffle everything back around.

[Spacing between Table Cells in Affinity Publisher]

8 hours ago, Silly Sausage said:

Was just hoping there would be a way to define the lines as transparent, but that's a good workaround - thanks!

The lines of a table won't determine the width between your cells. You could make them 50 points thick and they would just run into and cover up the content in your cells. Consider them as decoration, not an element that adjust space between cells.

If you must have cells with a fill, but you want clear space between those cells, the best way to do that is with inserting dummy cells with no fill or stroke.

Your only other option would be to ditch the table entirely and grid out the whole thing, making individual boxes with text, and then adjust the spacing between them as it suits you - not as quick to go an edit should the content of your 'cells' change.

[[Fixed] Global Spot Color not updating in Text Style correctly when edited]

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.)

[Text Alignment Options]

+1 time infinity

['Books' and longer documents with sections]

On 12/26/2018 at 12:14 PM, cubesquareredux said:

You ask why I'm writing this particular book directly in Publisher. Answer: It's a bit of an experiment. The book is about 50% "primary text" and 50% images, charts, call-outs, and marginalia of various kinds. What I find is that the positioning of all these items on the page affects the text I want to write. If I were to write the text separately without thinking about what appears next to it on the page, I'd be writing a different (and inferior) book.

I suppose I could use a separate writing tool and then assemble collages on paper to see what's what — but I stopped doing that somewhere in the '80s.

So far, I've written only a few chapters; eventually there will be many. Each one is relatively short. While preparing each chapter, obviously I've kept to a sort of "master format" that's common to all chapters. If I have to copy/paste all files into one, or "add them up" in some other Affinity-designed way, there should not be any conflicts.

Yes, a "book" feature would be grand. (Honestly I'm still a little shocked that it wasn't built in from Day Zero.)

Thanks much for your comment. Additional advice would be more than welcome.

 

I have been on a Mac (at home) since childhood. My father worked as a computer IT (back when discs were the size of pizzas) for DuPont and always came home complaining about all of the problems with Microsoft, Dell, etc. So I've learned to navigate Apple-friendly software alternatives since I was about 8 years old. (I started on Graphic Converter AGES ago!)

As the majority of my paid work is creating layouts and wrangling text, I would have preferred to 'story board' something of this experimental nature, before assembling. This way I can set myself a sort of guide for how many total pages I want to aim to end up with, what each chapter should contain, and what each page in a chapter should contain (more or less). I find it always easier to edit down text. I'd start laying out each chapter by blocking/framing, adding the essential images, charts, etc. And then add the primary text - if there's too much text for a particular space, I edit down OR consider adding a 2-4 pages to the chapter.

For layouts and design, I prefer to plan, then do. But I recognize everyone works a bit differently. Since this is your own project, and not client work, I say do what works best for you!

I agree the 'book' feature would be the best way to tackle this from a layout perspective - but as we don't know yet whether this will be included once Publisher is released from beta, at this stage I'd recommend keeping it all together.

The biggest thing I've laid out so far on Publisher beta is a 20 page 'newsletter/magazine' for a client. It worked quite well (even better once they fixed the master page bug) and I'm already planning to continue with doing this project in Publisher each issue, ready to throw my cash at Affinity as soon as they release the paid version.

I have one other annual client project that's 100+ pages and 8 beefy 'chapters' to wrangle, which is currently in InDesign and uses their 'book' feature. Though, the more I think of it, the only reason I made it a book in the first place was because ID was soooo clunky on my older Mac once you got past 25 pages or so that it was a total headache every time I had to open and work on that one massive file. Maybe Publisher (like Designer & Photo) will handle these same tasks smoother, and not having a 'book' feature when they release it from beta won't hinder my ability to cut the Adobe cord completely. 

Still would be nice, especially if a client comes back with a request to completely rearrange chapter orders!

['Books' and longer documents with sections]

On 12/24/2018 at 12:26 PM, cubesquareredux said:

If I may add a related question:

Writing a particular book at the moment, I find it easier to handle files chapter by chapter: these are smallish files I can create, edit, and circulate for review.

When the time comes, is there a simple way to merge my chapter files, create a global table of contents, create a global index, and so on?

Or should I be working with one big "book" file from the start?

Thanks for any advice.

Is there any reason you're doing this directly in Publisher first? I would think basic text files (LibraOffice, Word, etc.) would be the best for writing, editing, and circulating chapters of a book. Publisher is more for final layout, I would think. Unless your book includes a lot of images you want proofed at the same time?

If the are already individually saved in Publisher, as it's still in Beta, I think your best bet of merging would be to open all of the individual files, and then copy/paste into a comprehensive file? Since there is currently no 'book' feature. Then the rest (TOC and indexing) can all be done in the one file.

Otherwise, if you're not in a hurry, I'd suggest waiting and hope they implement a 'book' feature so you don't have to go through that tedious work.

[Print book layout]

+1 !!

(I did not find this thread when I first searched for one and then ended up posting my own, but I more or less requested the same thing. A way to manage longer documents is a must!)

[Auto Indexing]

On 12/24/2018 at 5:52 PM, Michail said:

What do you mean by auto index? This is how an index works: You search for the words manually and add them as an index entry. At the end you create the index. Only the creation works automatically, but not the indexing. How should the program know which terms you want in the index?

You swear that InDesign can do that. But InDesign does it exactly as I just described it.

Well then, let's make Publisher better than ID? :-D 

I would think, just like a search and replace, or the TOC, you could tell the program 'search for all instances of X and return the page number this entry occurs on'. You could do this for each word you need to be indexed but you wouldn't have to search for each them manually and stop to manually insert a marker each time. You'd simply input the desired word in the appropriate field when building the index, and the program inserts the page number(s).

This is what I mean by 'auto index' - as opposed to the highly manually 'search, stop, insert index tag, search, stop, insert index tag' of the current workflow, which I think would grow tedious quickly. Like GREP or even Search & Replace, you could specify that words only with a specific format should be considered to tag for indexing.

['Books' and longer documents with sections]

After poking around thoroughly in Publisher, I did not see one feature that I find incredibly handy in ID - creating 'books'. I saw another thread where someone suggested using Publisher's 'Sections' as a way to handle longer documents, though I'm not sure this is the way to go and keep the program running smoothly.

ID handles books by creating a 'container' into which you can add or remove other ID files as 'sections' - allowing you to rearrange each as needed, add/remove pages inside each and automatically updating page numbers as you shift things around. You can even tell the 'book' that all section's styles should be children of 1 master style, allowing you to only have to update a style once to populate it across all sections.

There is a longish publication I work on each year that I find easiest to wrangle by creating it as a 'book' instead of a 100+ page file. I'm not 100% sure I'd want to attempt this same publication in Publisher without some way to better manage these sections.

I'm not saying Affinity should recreate what Adobe has done - I am suggesting they could add this feature and have it work even better than Adobe's does. :-)

 

[Auto Indexing]

Are there any plans to create an auto-index feature? I swear ID can do this - but all I see in the Publisher Beta is the tedious 'insert index marker' by hand, page by page, for each and every topic you want to index. Surely when you're laying out a reference book or other large publication, there's a more automated way to do this then searching for each instance of a word and then inserting a marker?

Or, like Table of Contents, could there be a way to have words with special formatting automatically flagged to be included in the index?

As it is, indexing currently feels incredibly clunky and incomplete. I do realize this is still in Beta though, so curiosity prompts me to ask if polishing up the index feature is something slated for future releases?

On a positive note, I found the TOC very easy to set up, format, and create - quickly and effectively. Great job!

[Insert Index -- how?]

On 10/23/2018 at 1:39 PM, jmwellborn said:

I hope so.   And also my Command +A problem.  I am now on my MAC (Sierra) and first checked with Apple Pages to see if Command + A works.  Yes, it does.   So I closed it out and opened Publisher (v. 145) and opened the document with the index which wouldn't respond to Command +A or to VIEW>Select All yesterday.   The document has 57 pages of text, and a new page 58 with the index (now opened with your handy workaround) neatly arranged.   I clicked inside the text frame and tried Command +A again.   Nothing.   I tried VIEW>Select all.  Nothing.  So I went into the document to a random page (i.e. 37) and tried Command + A.   Worked perfectly.   Back to the index page 58, Command + A refused.   So I closed that .afpub file and went to another "Saved As" version of the same attempt at an index.  Command + A didn't work.   But then I went to a "Help" page I have created for myself, with a full-page text frame containing the saved index (from the original page 58 in another file) plus one new small text frame and a placed screenshot that I had made of the steps I need to take.   I clicked inside the whole-page text frame, hit Command + A, and lo and behold, the INDEX portion of the page was highlighted.  Not the other small  text frame (which was placed inside the full-page text frame) or the placed screen shot.   

So then I went back to the first document (which wouldn't respond) and hit Command + A.    It worked.

There is definitely a gremlin in there somewhere.   I do hope the developers can help to figure out this whole Insert Index thing!!!!

I know this OP is a bit old, but when I saw your mention of Command+A problem, I know this often crops up in Adobe products as well. It's typically a problem of some other program running in the background hogging the keyboard. Close each one in turn and see if Command+A starts working again. I had this happen once and the culprit was Chrome for some reason! Usually a quit all and restart fixes it as well - but if not, see what else you have running in the background... and then let Affinity know in case there's some way they can wrestle control back from the unruly program that's overriding Affinity.

[[Implemented] Data merge]

+++++++1

While I've already done a 20 page newsletter/magazine on the beta Publisher with ease, the other annual project I have definitely requires a data merge feature for me to make the full switch. I use it to compile a membership listing from a spreadsheet, and having to go in and format 300 entries by hand would be KILLER. With data merge, I simply tell ID which fields should be formatted in which way, and then let my computer churn away creating the merge.

Please please please tell me this is on your priority list for features to add to Publisher! For me, it's the only critical thing missing to make the complete switch.

[Myriad Pro OTF Ordinals etc not working]

1 hour ago, Dave Harris said:

There are several things happening here. First, the Ordinal OpenType feature often only applies to ^o or ^a, which are used in Spanish and related languages for masculine and feminine gendered numbers. Many fonts implement it for those and not for English ordinals like 3rd. Publisher doesn't do fake ordinals currently, and if it did it would probably only do so if the font had no support at all, so as not to interfere with the font author's intent or get mismatched glyphs.

Second, Publisher has two ways of setting Superscript. The typographic way is based on replacing glyphs, and is either implemented by OpenType or by switching Unicode characters. Either way, it only works for characters that have suitable superscript glyphs defined by the font. This is why the Superscript from the Typography section works for 3 and not for rd. The other way just scales and offsets the original glyphs, and as such works for all characters. This one is set from the Positioning and Transform section and is probably what you should be using here.

Third, Publisher does indeed have an option Preferences > Auto-Correct > Superscript ordinals as they are typed and it sounds like you have this enabled on one machine and not the other. It switches on the scale and offset method, so always works. That this is working on your desktop makes me believe that Publisher is working as designed, and that you are simply using Superscript from the Typography section rather than the Positioning and Transform section.

Thanks so much for the detailed response, Dave!

I just went and checked these options under Preferences > Auto-Correct > Superscript ordinals as they are typed and it is checked on my laptop. So I tried the old "uncheck then check again" and now superscript is working just fine! Weird bug? Or weird user error.  If it happens on my laptop again I'll document it.

(Also great to know about this option under Positioning and Transform. Thanks!)

[Myriad Pro OTF Ordinals etc not working]

8 minutes ago, MikeW said:

With APub, it's a bit easier to get to fake Superscript. And that is what ID/QXP would do with this font that doesn't have these characters as part of an ordinal feature.

You can create a character style and use it to apply Superscript to what would otherwise be ordinals in a font that has a fuller set of them. Look over on the right-side for setting a character style to be superscript.

Yes, I tried that too. On my laptop, it wouldn't work. The only way I could get a superscript look was to manually adjust the font point and baseline. Creating a style and applying it resulted in no change whatsoever. Superscript simply didn't happen, for any text, regardless of what I selected.

 I'm pretty sure this is some sort of bug in Affinity Publisher running on Mojave.

[Myriad Pro OTF Ordinals etc not working]

1 hour ago, Mithferion said:

Maybe it's a dumb question but, can you do this on another program? I ask that because in Designer, I have mixed results depending on the font I use to get this result:

Best regards!

Yes, I'm using the exact same font family I was using in ID and superscript & ordinals work just fine. So I guess ID is 'faking' ordinals? But if they are faking ordinals, why doesn't using 'superscript' in Publisher work instead? It kept making the 3 superscript, and the 'rd' stayed normal.

So, I opened the same file on my desktop, which runs Sierra 10.12.6 - Publisher 1.7.0.162 - and it automatically makes superscript out of the "rd" when it comes after a number and I hit the space key! So what gives? Am I missing a preference in Publisher that is active on my desktop but turned off on my laptop, or is there something between the 2 different OS versions that's causing one Publisher to create the superscript, and the other to not?

[Myriad Pro OTF Ordinals etc not working]

This is how I want it to look. I had to nerf this by selecting the 'rd' and making it a smaller point size, and then adjusting the baseline for those 2 letters. Would love to know if I'm missing something or if this is a bug of some sort. Thanks!

[Myriad Pro OTF Ordinals etc not working]

Ok, so I played around with it some more, thinking maybe it's because I'm coming over from Adobe ID. I've selected the "3rd" but for some reason the "rd" isn't an option to become superscript/ordinal, only the 3??

How do I get the 'rd' to be superscript??

[Myriad Pro OTF Ordinals etc not working]

I am using Myriad Pro as body text, and want to change some text to ordinals. However, whatever I choose (ordinal, subscript, superscript, etc.) the text remains unchanged. When I pull up the Typography Pane, and tell it to show all font features, every single option aside from capitals looks exactly the same, and the 'fraction' and 'ordinal' check boxes are grayed out. Can you please tell me why Publisher won't display these options for an OFT? Thanks!

I am on Mojave 10.14.1, running Publisher 1.7.0.162

[Setting margins in master pages]

1 hour ago, MikeW said:

Why a master page (or master pages) isn't created in a layout application when a new document is created is beyond my ability to rationalize the thinking behind this choice. If someone doesn't desire using the master page then they don't need to.

If a master page was created automatically at document creation, then it seems a no-brainer to have it actually control the document margins and if someone later desires to alter margins they can do so on the master page(s) and it would simply apply to the document. The facility is present in the UI already and so other than how margins would automatically be applied to all pages using the altered master page(s) programmatically, the UI is there to do so.

So yes, please do consider this choice. 

Important to note that you can also have more than one Master page. So if you have standard margins, but have a spread in your layout that deviates from this, you can always create a separate master to apply to only those pages. Or even as ID does where you can link up Master pages - so that your primary Master page contains the thematic elements that exist in the entire spread, and then those child master pages can add additional elements. If something needs to change in the theme, you edit the primary Master page and ALL of the child master pages are updated.

If you happed to set margins up this way, then they should update as well. When you're working with 100+ page publications, these sorts of tools are incredibly essential for workflow.

[Setting Margins & Columns w/ Gutters]

8 minutes ago, Wim Daniels said:

What I find annoying is that the snapping does not seem to work on the columns in a text frame. I've activated all options in the snapping manager, but objects don't snap to the columns in a text frame. Seems like a must have to me. Or am I missing something here?

If snapping would work as expected, one can use a text frame to set up the guides on the master page, or use a (empty) text frame as a snapping guide on the fly.

This is where having the columns set up in the Master page would make a whole lot more sense. Not a text frame, but simple column guides, as I originally posted above.

In this way they should function as guides, and thus objects should snap to them just as they should to other design elements.

Currently, the best work around is to set up actual guides on your Master were you gutters would be (doing the math to make sure everything works out) and then your objects should automatically snap to them, regardless of having a text frame in place or not.