GarryP
-
Posts
10,687 -
Joined
-
Last visited
Posts posted by GarryP
-
-
Windows 10 Home 1809, Publisher 1.7.0.249.
I have a small document where I used a certain font - Aileron - in many places but decided it didn't look as good as I had originally hoped.
I went through the document changing it where necessary, then I went into the Font Manager to see if I had done all the changes I needed to.
However, when I choose the font I want to locate and press the "Locate" button, no layers or text gets selected. Nothing at all happens as far as I can see.
I'm fairly sure that I've made all the changes - I've even checked all the text styles (I think), including the TOC ones - but it seems that the Font Manager thinks the old font is still in there somewhere. The same font is also listed in the "Used" tab of the font selector.
Is there anything else I can try?
I didn't want to put this down as a bug until I thought I had exhausted my options. -
Sorry, slip of the keyboard.
What I should have said was, "the text frames in which don't have as much functionality as those in Publisher".
Maybe a better example is creating a poster where you start the illustration stuff in Designer with some basic artistic text, then move over to Publisher to do the fancy typographic stuff - text wrap, baseline grid, etc. - and then move back to Designer to finish things up.
Either way, being able to convert would be nice but not absolutely necessary.
I was just wondering if anyone knew of a better way. -
I can't find anything in the Help about this but it seems like a reasonable thing to want to do.
It would be nice to be able to easily convert an artistic text layer to a text frame so I can take advantage of the extra functionality without having to manually create new text frames and copying the text over.
Is there any way of doing this easily?
On example where this would be useful is if you had a page originally created in Designer - which doesn't have text frames - that you brought over to Publisher for further editing. -
-
That's fine. Just thought I'd check.
-
You're welcome.
Did you deliberately choose to use grey section backgrounds and white backgrounds as 'picture frames'? -
Is it just me - it often is - or is there something wrong with some of the text in this document?
For instance, on the Trees page - page 95 - the page number, title, subtitle and "Go to TOC" are rasterised while the rest is vector.
I've looked at it in Acrobat Reader DC, Firefox and Chrome and they all have that text rasterised.
Was this expected? -
I thought I might be able to get away with grouping the table with its background layer - rather than the background layer containing the table - but I get the same problems after resizing the group.
I'll probably stick to having the tables as separate layers until this is fixed. What I need to do isn't very complex so doing it as simply as possible will work for me in this case. -
That might take a while to organise as I've never recorded dual monitors before.
I've just looked at a video on how to do it with Open Broadcaster - which I've never used before - and it looks a bit fiddly.
Is there any particular bit of the process you need to see? -
carl123, I've just moved the table out of the "Table" layer - didn't know it was in another layer but I must have done that - and the table looks like it's working normally now.
I tried the same with the original document I had the problem with - three separate tables - and that 'fix' works there too.
Moving the tables back into their original layers makes the problem come back, but if I then move the tables to brand new layers the original problem isn't there, until I start resizing the containing layer.Pauls, I've been able to re-create the problem and have saved the history in the attached document.
Basically all I did was:
* create a new document;
* create a new table;
* create a new layer;
* put the table in the layer;
* resize the layer a few times. -
Very nice.
I have a few notes/comments:
* Unless I've misinterpreted, you have spelt "Colosseum" wrong in the legend for Sitiri.
* I don't see any mention of what the dashed red lines are. Are they just city boundaries?
* What are the brown lines that seem to come under everything else? Are they tunnels?
* Do you need to mention what the rivers and lakes are in the legend(s)? Is it obvious?
* The meaning of the graphic for 'slope' might need a mention, if that's what it is.
* In some places it's a bit difficult to see the legends.
* Noticed that the T-junction south of Sitiri has a line going though it. Just a tiny detail that I happened to spot.
* I assume that the main roads have been exaggerated for practical purposes. Otherwise they'd be about half a mile wide.
* The text under "Ouaphris" could be better moved down a bit.
* These are massive cities. The somehow-strangely-perfectly-circular city wall seems to be around 800 miles in length and the enclosed area is about 15 times the size of New York. It's your map, and that's fine, but is this realistic given the level of technology - e.g. no train tracks - that the map seems to suggest?Anyway, my little comments aside, lovely work.
-
Pauls, the problem occurred while I was making a lot of edits to a table so I can't really say what happened to get me to the point where it went wrong. Things were fine until they just weren't.
I was using Publisher on a 100%-scale display.
If I add a new table to a brand new document - even if the problem document is also in memory - then I don't initially see any problems, but if I add a new table to the document that already has the problem then the same problem is also evident in the new table.
It seems like once a document is 'afflicted' with the problem, all new tables in that document are also 'infected'.
Sorry I can't be more precise about how it happened, it was just a case of "Try this, experiment with that, have a go at this other thing, oh, hang on, when did that happen?" -
Windows 10 Home 1809, Publisher 1.7.0.249.
Apologies for the non-specific title of the post but I couldn't think of anything more precise that covers everything.
Have a look at the attached GIF and you will see:
* The row headers are not aligned with the rows;
* The later row headers are 'greyed out' when the row is not selected;
* The later row headers don't have the 'context arrow' for the drop-down menu;
* The column headers are not aligned with the columns;
* The column header dividers, when dragged, do some very strange things.
(Apologies for some of the mistaken mouse movements, it's sometimes very difficult to get the cursor exactly where you want to get the correct pointer. Also, ignore the shear, I didn't mean to do that - difficulty getting the correct pointer.)I've attached the document for testing.
-
-
-
Windows 10 Home 1809, Publisher 1.7.0.249.
Have a look at the attached GIF where:
* I create a new document - custom-sized at 2x3 inches (purely for demonstration purposes);
* Page Preset says "Custom", as expected;
* I close that document;
* I go to create a new document;
* Page Preset now says "A4" but the size is still 2x3 inches;
* I re-select A4 from the Page Presets but the size is still 2x3 inches;
* I select a different Document Units but the size is still the equivalent of 2x3 inches;
* To get what I want, I have to select a different Page Preset, then select the Page Preset that I actually want, and then re-select the Document Units that I want.I don't think this is working the way it should be.
If the Page Preset says A4 then I should be able to assume that the page size is whatever A4 is in whatever the Units is set to. I shouldn't need to check that the Width and Height are correct for the preset. (This would be especially difficult to spot if the page size was close to - but not exactly the same as - the preset size.) In other words, if the page size is not exactly equivalent to an existing preset then the preset should be "Custom".I only found this issue after I thought the Zoom function wasn't working when I zoomed a recently-made - apparently A4-sized - document to 100% and found it was way smaller than it should be. (A 2x3 inches document zoomed-to-fit looks exactly the same on-screen as a 8x12 inches document zoomed-to-fit.) When I created the document I noticed that the Preset said A4 - so I assumed that was correct - but the page size was actually 5.8x7.9 inches (from a previous document).
This isn't a huge problem while the software is still in beta - we're not supposed to be creating "real" document with it - but I would say it could be a really big issue if someone creates a magazine or a book only to find out, at the very end, that they've done it all on wrongly-sized pages. (Imagine creating a 100-page magazine and only finding out at the print shop that you've used a 230mm page width instead of the 210mm you needed.)
-
You're welcome.
-
Hi Adam.
I would have to experiment more with how things are but I think what you're saying sounds right.
If every master page that was applied to a page/spread was 'active' and I had, for example, three applied master pages, each with different margins, guides and column guides then doing any layout work could be very awkward as the margins and guides on each master page would fight with each other for snapping.
This issue came from - as far as I can remember - some experimentation I was doing with a magazine layout where I had the guides for each area of the page layout on different master pages: https://forum.affinity.serif.com/index.php?/topic/75807-magazine-spread-experiment-radio-times/
For example, the guides for the left-hand picture layout were on one master page and the guides for the bottom-right-hand box-out were on another. I could apply the relevant master page to the spread when needed and then remove the master page when I was done with it.
I have a feeling that this wasn't the best way to be doing things but I'm still getting to grips with this.
If the rule is that the 'active' master page - for layout purposes - is always the one that is at the bottom of the layer stack then that sounds like a good and sensible way to go, certainly better than skipping certain master pages under specific conditions which would, as you say, probably cause confusion.
Dragging the master page that I want to use for layout at any particular moment to the bottom of the stack is very easy to do so that sounds like a perfectly reasonable way to go.
As long as this is highlighted in the documentation then I would say that this part of the issue I raised can be closed as far as I'm concerned (although I haven't been able to check the other parts of the issue - guides going missing or being "renumbered" - yet).
Cheers. -
-
Lovely stuff. Great to watch an expert at work.
-
To get the splash screen to show at start-up, go to menu "Help -> Welcome..." and check the "Show this panel on startup" box at the bottom-left of the window.
-
I notice that this clicking action is mentioned in the Help a few times but the wording is different each time and the name of these things is vague: "readout", "blank cell header", "dark empty header", etc. A single name needs to be chosen and used consistently. I didn't notice the drag function in the documentation at all (I found it by experimenting), but I could have missed it.
Also, the "Table/Cell formatting" panel isn't fully documented at the moment. Hopefully that will change once the exact functionality has been 'locked in'. Some kind of graphic example might help people to see what's what.
-
Windows 10 Home 1809, Publisher 1.7.0.249.
When I drag the double-arrow tag at the bottom-left or top-right of a table (I don't know the proper name and can't find it in the Help) it doesn't always produce a new column or row.
See the attached GIF where dragging from the tab the first time usually creates a new row/column but after that it only starts to create rows/columns once I've dragged to two row/column heights/widths.
Not a major issue, just thought I'd mention it. -
Windows 10 Home 1809, Publisher 1.7.0.249.
Note: This issue also applies to Columns.
When I select multiple rows on a table and choose "Delete Row(s)" from the little drop-down arrow menu - on any row - only one row is deleted.
However, if I right-click with multiple rows selected and choose "Delete Row(s)" from the contextual menu then the correct number of rows is deleted.
I think both methods should do the same thing, which is to delete all of the selected rows, otherwise the "(s)" suffix is confusing.P.S. It would also be nice to be able to insert multiple rows/columns but that's maybe something for separate request.
Tables: Delete Row(s): different behavior
in [ARCHIVE] Publisher beta on Windows threads
Posted
The developers have been notified: