Jump to content
You must now use your email address to sign in [click for more info] ×

IgorRock

Members
  • Posts

    16
  • Joined

  • Last visited

  1. Sorry, but nope, I haven't found any good solution for this. I ended up manually adding paragraph breaks (sometimes even mid-sentence) as the last thing at a column's end before I exported the PDF (which sucks, because I have to be careful with corrections or additions now - I always have to check if all breaks are still at the right spot, which for some chapters means controlling 15-20 pages). 😒
  2. Some questions about the linked resources: Does that bug affect all linked resources (I use PNG for most other images in those other documents), or just .afphoto (or .afdesign) ones? And do I need to delete and insert them again, or is it sufficient to just go to the resource manager and switch them all to "embedded"?
  3. Well, I'll be damned. I renamed the afphoto file, opened the example, clicked on "no" - and it doesn't crash. Closed it, renamed it back to the old name, opened it: immediate crash again. OK, renamed it again, opened the file, clicked "no", deleted the linked image from the master page, renamed it back, put it in again, but changed it to "embedded", saved the file under a new name. Opens just fine three times in a row! Which now makes me wonder why it didn't crash every time with the other documents, and why I could prevent it from crashing by updating the index in the bigger files?!? Well, I guess I'll now have to replace all the images in the other documents with embedded versions to see if that fix works with them, too... 🙄 Just for completeness, I've attached the .afphoto file with this answer, would be interesting to see if the example document crashes for others with it, too (I guess one would have to replace it's path in the resource manager, though). Thank you very much for your help! 🙂 Old_Paper-002-for-CMYK-print.afphoto
  4. Hi support, it looks like I found a - now more or less reproducible - issue with the index in Affinity Publisher V2.3.0. With three (bigger) documents I created, I very often get a crash to desktop (no alert or anything) just after loading them (normally about the time the auto-correction has just finished underlining wrong words). I'm using the German UI (but I have had the same crash when using the English version, too, so I guess this is not really relevant). All three documents have in common that they have an index. I've created a new document with some filler text to try it out, and it crashed Publisher basically every time I load it. I have attached it to this post. I can often prevent the crash with my bigger documents if I'm fast enough to click the "Update index" button (in "Index" studio) before it has finished rendering after loading (even though it doesn't work reliably with the below test document), which seems to point at some issues with the index itself. This bug is really annoying, especially when you are just loading a second document to check something in there, only for Publisher to crash, and as such losing your work since the last save from the document you were working with at that time you loaded the second document! Can you please have a look and get this fixed (I have this problem basically since V2.1 already, but couldn't easily reproduce or pinpoint it. I think it worked with V2.0 without issues, if I remember it correctly). My system: Windows 10 Home, 22H2, build 19045.3803 Hardware acceleration setting doesn't change anything, it crashes with enabled and disabled. 16 GB RAM, SSD Harddisks AMD Ryzen 5 2600 Six-Core Processor 3.40 GHz NVidia GeForce RTX 2060 (6 GB) I have a small Adesso tablet connected, but don't use it for Publisher I have an Elgato Stream Deck (15 key version) connected as well, but again don't use it for Publisher Index-Issue_Example.afpub
  5. Since 2.1.1 is out, I installed the new version and did another test. One of the documents now seems to work fine, but the other one is still crashing the program shortly after it's being loaded. The effect is that the blue circle ("working") shows up, then it crashes. I tried using the "pages" studio to scroll and tried to update the table of content immediately after loading, too, with the same result - it loads the file just fine, displays both the working area, the pages studio and updates the table of content, but crashes just seconds later. As such, I've reverted back to 2.0.4 again. Can you please create a new dropbox, so I can upload the file in question confidentially? PS: I'm using publisher with German language settings.
  6. I already rolled back, since I'm on a tight schedule right now. Maybe I'll find some time on the weekend to give it a try. How does it work with confidentiality and copyright if I upload a document to your Dropbox?
  7. I get a crash without any notice (the program just "vanishes" shortly after the rotating wheel "wait for me" mouse cursor appears) after loading any of my documents. Shortly after loading a document (I tried three different ones) the mouse cursor changes to the pointer cursor with the blue "working" circle besides it, then changes back, program is unresponsive and just closes a couple of second later without any message. These documents worked fine in 2.0.4, I worked on all three every day for hours over the last weeks. I tried it both with hardware acceleration on and off, no difference. Will revert to 2.0.4 for now, so I can work (you should by now have some crash reports, if that automatic reporting works...).
  8. Just to be sure it's not a language related problem, I switched APub to English, but the result is the same, so it's obviously not that. And I forgot to mention that I'm using V2.0.4.
  9. Strange, in my Version, all other defined character styles don't show up when I edit the headline style (please note there is no scroll bar, so it's not that I forgot to scroll): And I have a lot of character styles defined in non TOC edit mode: Any idea what I might be doing differently? 🤔🤨
  10. Hi MikeTO, Thank you very much for your example (using a unicode character instead of the Numberpile font might come handy for other projects later on), but I think you might have misunderstood the real issue I encountered. In your example you're using unicode 2460 for the circled one (and I know there is unicode 2776 for the negative circled one, too), but the first problem is that the fonts I use (Alegreya Sans SC for the headline and Merriweather for TOC level 2, which are both free Google fonts I can use to publish my stuff without having to buy a font license to do so) both don't provide those special characters, so AP uses some standard ones from another font, so I have another font showing up in my document (of which I'm not even sure if I can use it commercially without having to buy another license). And I could exchange the symbols on the map to use these, too, and could even use the same trick to get the white background in the headline in the text itself, as can be seen in this screenshot (right side shows the decoded unicodes, the first one is using the numberpile font for the circled five as in my original post). But the real problem with the TOC is the same, even with the circled numbers using unicode - because there is no "add TOC character style" button available, I cannot add the character style needed for the "Initial word" to have two colors and the 0.8pt "border" to fill out the number instead of having it transparent, as can be seen here: See what I mean? Your solution to use those unicode characters works fine as long as one doesn't need to have the circled number in exactly the same format (two colored) as it is on the map or in the heading itself (the TOC should help people to find the corresponding page easier when looking at that map, so the symbols should be exactly the same). But it would be the same problem if I had (for some design reasons) headlines which e.g. have the Initial word(s) in bold (Like "Basement: The first room" and "Basement: The second room" - just a simple bad example to make it more clear ), and this layout should be mirrored in the TOC as well. As long as you cannot add "TOC character styles" yourself, every TOC entry is uniform, without being able to use Initial Words at all (unless you want them to use the same format as for the number of the same or another TOC level, that is, since the TOC character style for those gets created automatically by AP - which is what I used as a workaround).
  11. I guess this is an oversight by Serif: I have some headlines which use the Numberpile font to have a marker in front of them (which matches the ones used on a map on another page), which looks like this in the text: This is basically an additional "Headline 2" style which uses the "Initial words" option to use the Numberpile font for the initial word (which in this case is just a "B", which matches the number "1" in a circle in that font, the two colour effect - the character in Numberpile as such would just the white circle with a transparent "1" in the middle - was done by using a 0.8pt border for the character, in case somebody needs to do this, too ). This worked just fine in the text, but in the TOC, it of course shows up as a "B", since the TOC entry uses the same style for the whole line (besides the number, for which there is an additional TOC character style): Not a problem, since I can change the "Initial words" option for that TOC style here, too, right? Well, actually YES, it is a problem, since you cannot create additional character styles when working on TOC styles, the icon is greyed out and not clickable: So the only character styles available to use in TOC styles are the ones for the different TOC numbers for the TOC levels (or styles to list you turned on). As such, those are the only character styles you can use in the "initial word" option of those TOC styles, too. Right now, I am using a workaround to get my desired result (I simply changed one of the TOC number styles which don't show up in my TOC, because I'm not using the dark section names in this document, to the Numberpile font with the border and then used that character style for the initial words), but this is of course for obvious reasons not ideal: Is this a bug/oversight/missing feature, or did I miss something myself here?
  12. Yes. Somehow I expected a comment like that which totally misses the point I was making. The argument was that somebody would think that something ends when there is an bottom line of a box at the end of a column. Please note that the table cells in those tables don't have horizontal lines between them, only the different tables have those. As such, this is exactly the same thing as with a paragraph which would continue on the next page. On the contrary, with the table it's actually worse, since there are no unfinished or half sentences at the end (as with a paragraph), just some numbers, so it's actually worse with a table than with a paragraph, since the reader only realizes that there is something missing once he reads the next column. Nevertheless, they still choose to not change their layout to put the whole tables in a separate column or anything, and that book was more than successful. And that's what I meant: It's a design choice somebody made, which as such should not be predetermined by the tool you're using.
  13. I understand your point, but isn't that something which I as the designer should decide for my own layout? For example, this this is a page from the German manual of the original D&D, which does exactly what I asked for (without the background colour, though), and it looks like people haven't had a problem with that, given that it's the biggest RPG on the market for a few decades by now... (I've blacked out the text and values to not get into any copyright troubles for posting this) I guess you're right in regards that I'll have to go with just the background and maybe a thicker line on both sides instead (which is another design used by other RPG as well), at least for now. But I still think there should be an option to add these lines on a paragraph break if wanted.
  14. Hi all, I've run into an issue with the automatic column break and paragraph text decorations, and was wondering if I'm missing something (or if Publisher is). I'm writing a role playing game module and I want to add some text which the game master should read out loud (which should be clearly visible to the reader), which means that text needs to be at the correct spot in the surrounding text and move with it if I edit any text before it or add some illustrations (I'm still at the writing and editing stage, so some small text changes can cause bigger changes in the layout because of text wrapping etc.). I know that once I've finished everything, I could just manually adjust the text (e.g. split a paragraph into two at the right position) to get the wanted effect, but I think there should be a better way. As you can see, I've created a paragraph style for a boxed text (this is not a text frame, just some text which has a different background and a 1 pt box around it because of a paragraph style with decorations enabled). The problem is that when Publisher auto-wraps a paragraph with these decorations, it literally cuts them off, which means that in the first column, there is no lower line (or background) for the text, while in the new column, there ist no upper line (and no background, either) before the text starts. Is there any way to get Publisher to adding those missing parts when a paragraph wraps onto a new column or page? I guess if I use a text frame and just pin it in place at the correct position in the text, the whole frame would be moved to the new page, which would leave me with a big empty space in the first column, and is - again - not what I want. I guess I could just use the left and/or right line together with the background (so it's not a boxed text anymore, but still clearly visible), but I would prefer to have a full box around the text. Any ideas?
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.