Ormhaugen
-
Posts
29 -
Joined
-
Last visited
Posts posted by Ormhaugen
-
-
As for the overrides: I have been using tracking in some body paragraphs to adjust the text to column endings. But I can't find that I'm using paragraph returns instead of text wrapping when placing pictures.
Maybe a fluke, but on my end when I select the heading and type over it, the text in the running headers changes accordingly on all the following pages. So to me this seems to be normal. I'm still not understanding what's happening in the first dokument.
-
Thanks for looking into this, but I don't understand, because the headlines in all the chapters are made the same way, also in those where running headers are ok.
Attaching a chapter where everything is ok. Do you see any differance?
-
I have a book containing 12 chapters. On the master pages I have set up running headers showing the style of the chapter title on top of the pages left and right. On 7 chapters everything is working as expected, on 5 chapters the running headers are only showing up on the first page, not on the following pages. I can see when opening one of those not working chapters that <Running Headers> is shown for a sec or two, then blank.
All the chapters are layed out using the same template, and the running header frames (setup) are copied from the master pages for one of the working chapters and then copied into the master pages for all chapters.
I can't figure out what's preventing the running headers from showing up where they should. I'm attaching one of the files that are not working. Could anybody please have a look to see what might be wrong?
Geir
-
Thanks for helping
Quotechapters need to be set up to have an even number pages
This is how QuarkExpress handles chapters in a book. I'm making a yearbook with many authors, the articles are of different length so it would be a nigtmare to adjust.
QuoteParagraph Style (call it Page numbers) which uses Away from Spine for its alignment
I have this, doesn't seem to matter.
But, I have found a solution, though not automatic: If I change the starting page from right to left in the chapters causing trouble, and exporting area "All chapters as pages" everything seems to work OK. You then of cause have to have the chapters in the final order. So you don't have the same freedom moving chapters up/down. But it works.
I miss Ventura Publisher taking care of this already in the 90's
Geir
-
That's one step forward, thank you Mike. But I'm not quite through. I'll try to explain:
If I now export the book with area "All chapters" chosen, AffPub does something odd: if a chapter ends with an even number, say page 16, I get two facing pages, the end of the chapter left, then a blank page (area) to the right. The next chapter starts with an odd number to the right, say 17, but now a blank facing page (area) to the left.
If I export the book with area "All chapters as pages" I get no blank pages, but now another odd thing happens: a chapter ends with an odd number, correctly to the right, say 29. AffPub then jumps over number 30, the next chapter starts with 31, the page placed to the left and the number to the right on that page.
I don't understand what's going on, if someone can shed som light on this, I'll be glad. To me the only solution now seems to be to collect the book by starting with the first chapter and the adding pages from file, 14 times in my case. That would work, but is very rigid compared to the book function.
number - All chapters.pdf numbers - All chapters as pages.pdf
-
-
I'm testing the book function in Affinity Publisher 2.1.0. I now have a book with 14 chapters. It's mostly working OK (TOC, moving chapters etc.), but positioning of numbers gives me some problems. I use facing pages, and I want even numbers to the left on the left pages, odd numbers I want to the right on the right pages. All the chapters I have set to start with the first page to the right. But for some chapters this comes out wrong. If a chapter ends on a right page, then the next chapter starts to the left, but with an odd number to the left where there should have been an even number (see attached pdf). Any ideas how to fix this?
Geir
-
-
Thanks again.
Here comes the document. You could try updating the TOC and see what happens at your side.
Geir
-
Thanks for trying to help.
I can see which layer the line is associated with, but I can't do anything there - other than toggle on/off.
The line shows up underneath the style heading3 on 2 pages, under heading2 on one page. Have checked if there is anything associated with those styles (decorations etc.) - but there is nothing.
The only way I can see is to cover the line with a rectangel frame, - but there must be something......
-
I've started working on a book originally created in AffPub ver 1. Now I'm in ver 2.0.4. Everything seems to be OK, except for one thing: When I update the TOC, a mysterious line shows up at the bottom of each of the 3 TOC pages. It's covering ca. half of the page column, aligned right, as is the page numbers. I can't find where the line is coming from, I can't catch it to delete it.
I've opened the ver 1 document several times, and each time I do an update of the TOC this line shows up at the bottom of each TOC pages.
Anybody having an idea of what's causing the issue? See attached file.
Geir
-
-
Very good, that's it.
Thank you!
-
I'm about creating a book cover. The background is a one coloured frame and I want some handwritten text in a tif-file showing through the coloured frame on the front. How do I achieve that?
I've attached a testfile where I tried this: I lowered the opacity in the frame letting handwritten text showing through and then tried to alter the colour in the frame to match the original colour, showing in the frame to the left (back side of the cover). But it's difficult to get the original colour. There must be another way of doing this. How can I preserve the original colour?
Geir
-
-
I have always had my document units set to millimeters and font size to points. Now suddenly my AffPub only shows either mm or point. Thus if doc unit is set to mm, then font size is in mm. And if doc unit is point, then font is point. Not possible to separate, as far as I can find. An older beta-version shows doc units in mm and font in points, as expected (1.10.2.1187)
Anybody knows how to get back mm for document units and point for font size? AffPub 1.10.5.1342
Geir
-
Thank you so much Lagarto for your explanations and suggestions. As this print process har become urgent, I go for your last suggestion, not including color profile in the CMYK images. That is quick and with a few tests seem to give perfect results.
You saved my day, thanks again Lagarto.
Regards Geir
-
I'm about printing a book made in Publisher. The printer asks me to lower the colour coverage in some pictures, below 300 %. One image is especially problematic. In Photoshop it shows something like 155-160 % in a black area, shown in the red circle in the attached image file (the image is only a cut-out of a bigger image). When I place this image on a page in Affinity publisher and export this page to PDF the same area in the PDF file shows something like 330 % in the same area. I thought the colour coverage in the image file would correspond to the coverage in PDF file, but I've obviously got it wrong. But what is my mistake? Thanks for any help (or explanation).
Geir
Win 10, Affinity Publisher 1.10.1
-
You found what I missed. Thank you so much!
Geir
-
I have experienced a strange thing sometimes happening with picture frames. The situation: I have text in 2 columns and place a picture frame with a text frame attached (grouped) for image caption. When placing the frames where I want in one column suddenly part of the text in the neighbouring column is pushed to the next page. If I move the grouped frames to the other column, I get the text back to normal. I have text wrapping set to tight for both the picture frame and the text frame but distance from text is set to 0. I attach a APub file of just 2 pages, the picture is now in the left column and everything is correct. If I move the picture over to the right column, part of the text in the left column moves to page 2. Hope somebody will take the time to look into this because it's very annoying.
Geir
-
-
-
I have attached the afpub file and 2 PDF versions of page 79, where '79 Export' is produced with File-->Export-->PDF (for print) and show error in the typeface (very thin, almost unreadable).
'79 Print' is made with File-->Print-->Adobe PDF . This shows correct typeface.
If you take time to see the apub file you'll see similar errors on pages 23, 53, 59, 67 (caption) - and the text on the pages 72-73, 78-79
The font used in the captions is Times New Roma italic, the font in body text is Adobe Garamond Pro. I'm on Win 10.
I'd be very glad if you would be looking into this.
Geir
Grindabygg_24x24_ENDELEG_ExportPrint.pdf 79 Print.pdf 79_Export.pdf
-
Hello
I have created a book (108 pages) in AfPublisher (1.7.3.481). That's pretty much gone well. But when I now am about sending the book to the print shop, typeface errors appear on some pages.
Option 1:
I choose File -> Export -> PDF (for print). Attached file '79 low 'shows the problem. The typeface is thin, almost unreadable.
Option 2:
Attached file '79 best 'has been executed with File -> Print -> Adobe PDF and it is correct.
I prefer Alt.1 because Alt.2 has a tendency to distort the colors in some of the images.
Has anyone encountered similar problems when exporting?Geir
Running headers not always showing up
in Affinity on Desktop Questions (macOS and Windows)
Posted
Thank you Nathan for helping me understand what had happened.
In the meantime, before your answer, I had set up the 5 damaged chapters from scratch using the template for the whole book. This time everything is working OK.
The only thing I saw when exporting the whole book to PDF, was that only chapters that were opened in the book, exported correctly. Closed chapters only showed 'Running Header'. After having all chapters open in the book, the whole book exported as expected with all running headers showing correctly. But I guess that's how it's meant to work.