Jump to content


  • Content count

  • Joined

  • Last visited

About Tegwyn

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Overall, I think you should be fine. Details about my experience: The only image-based slowdown I've run into is when I used an image directly rather than placing it in a frame, and I set its wrapping to tight. The automatic wrapping outline had a very large number of nodes, and that chapter became sluggish. (I believe they have plans to fix this.) Things improved when I deleted most of the nodes to simplify the wrap outline. When I've put the images in frames and made the wrap outline myself, it's been fine. Every once in awhile, a change will take a long time to compute, and certain things are likely to cause crashes for me, such as editing global swatches (fixed in beta) or undoing and redoing table stuff. Saving takes awhile on my large project. (Also fixed in the beta version: be careful about placing docx files with tables and changing tables between pinned and unpinned. I've had that (apparently) corrupt my files before. If you're better than I am about saving new versions of your file frequently, then you won't have to redo as much if this happens. I'll be switching to the beta to keep this from happening again.) Publisher is generally a little laggy, but workable for me. I'm on a mid-range machine, so it might just be my computer. It's worth noting that most users don't seem to be encountering the issues I've mentioned. I've got a wimpier computer and a complicated document, so I don't want to scare you off. Publisher is a very cool program.
  2. If the paragraph style and the table are both set to ignore baseline grid, I agree they should do so. But I disagree that you shouldn't be able to disable baseline grid at the frame/table level. I think it's very nice to be able to make the exception at that point rather than to make extra child styles for each paragraph style you want to put in frames/tables that should ignore the baseline grid.
  3. @Angalanse For what it's worth, after my post, I ended up breaking it up into a different text flow for each chapter, and it helped enough for me to turn baseline grid back on. I was worried that splitting it up would break hyperlinks, but it did not. I went to each chapter break, selected the start of that chapter plus Ctrl+Shift+End (to select from there to the end of the text flow), cut, disconnected the text frame from the previous one, then pasted again. You might find this works for you if you have any spots where there is a clean split between pages (like a chapter title).
  4. Tegwyn

    Crash on save

    @Pauls (or anyone who can help), I'm getting crashes on save again. I can open the file but not save or save as. I tried lowering max RAM usage from the performance menu, using beta 502 instead, rebooting, uninstalling both 1.7.3 and the beta and reinstalling just 1.7.3, switching render engine from video card to WARP, and opening a previous version of the file. Unfortunately, trying to save the previous version broke that file, too. Making a copy of a file 2 versions old and opening and saving that worked. The last issue before the crash on save began was a full-computer crash, probably from running out of memory. I noticed RAM was getting close to 100%, and I believe I was trying to save at the time. After I rebooted, the crash on save problem started. It crashes on save even if it's nowhere near full RAM now. Possibly worth noting: I know I've had crash issues associated with table pinning, and this file did have a change where a table went from floated to unpinned. (So did the previous version after I reopened it and tried to resume from there, though it didn't successfully save and does not show that change on load.) I've attached the most up-to-date broken file and the first (aaa1b) and last (dfe7f) crash reports from this issue. Could you see if the file can be fixed, please? I'd be very grateful (again). dfe7fa1f-882a-4920-b767-5103d810bf9e.dmp aaa1b854-f67e-477b-b154-9b688da45870.dmp layout_v45.afpub
  5. Sure, go ahead and send me a dropbox link. I'm not at a computer with Publisher right now to double check, but I do have access to a version of the file that I believe had the issue. (Or, if an upload from a previous time you've helped hasn't been deleted yet, you could check that. It'd be the same document, and I think the problem affected all versions of my file.)
  6. Fwiw, PDF export with hyperlinks is still broken for me in Windows beta 502. I just found out reading this thread that this was why I couldn't export as pages, so I tried it in both production and beta versions and, sure enough, it starts working only if I turn off hyperlinks . I'd been working away under the assumption that there's just some messed up table I'd need to rebuild at some point to get it to export. Fortunately, Changing my document to not use facing pages fixes this for me (after a long wait for it to change all 400 pages, plus some tweaks to master pages that got a little messed up). It's just a little inconvenient, because now I can't see the pages side by side, but I'm designing it to look good if the user turns on facing pages in their PDF reader.
  7. I am getting a similar issue on the 502 beta (and the previous beta and on production version). I can create global swatches in a document palette, and I can open them, but clicking anywhere to actually change the color (or one of its components) causes Publisher to hang. Deleting one of these swatches does the same thing. On beta 502, the program eventually (after several minutes) changes/deletes the swatch and becomes responsive again. While it is non-responsive, it has elevated CPU usage (25-30% on my machine). When it finishes, it spikes to ~85% for another 30 seconds or so before dropping to idle. A color change proceeds in steps: after a minute or so of hanging, I can see the change to the color sliders (or whatever picker); then after another minute or so, the color picker closes, and objects with that swatch assigned change color; then after another several minutes, I can use the program again. Edit: On production version, when I try edit or delete the same swatch from that same document, the program crashes after about several seconds of hanging. So, the beta did fix something for my case.
  8. That's really interesting. After you said this, I experimented again. When I make a new spread using a master page, the text frames do not show bold applied in the context toolbar (even if I switch to edit detached). But, when I insert a TOC, it's all bold, and selecting the text frame now shows bold applied in the toolbar. If I make a new spread with no master page, then select the text frame tool, the context toolbar shows bold applied. Sure enough, if I make a frame and put in a TOC, it's bold. If I deselect bold in the toolbar, then make a frame and put in a TOC, it's normal. If I select the bold frame, then deselect bold, the TOC is no longer bold and remains so when I update the TOC. I didn't even realize the text frame tool had text formatting settings for the frame itself because they don't show in the text frame studio -- just the context toolbar. But I guess somewhere along the line, the tool got set to bold and was remembering it. Bug(?): When the text frame tool is set to bold, creating a spread from a master page will cause the text frames it inherits from the master page to be set to bold even if they aren't bold on the master page itself. At least, this happens to me in this one file. I wouldn't think the current state of the tool should affect inherited frames -- only frames you create with the tool.
  9. @Seneca Are you experiencing this on one of your files, too?
  10. @Jon P , if you still have the last file I uploaded / you fixed for me via dropbox, I believe that will exhibit the problem. (I was working on an updated version of that file when I ran into this issue.) If not, I can re-upload later if you want a sample to investigate. Either way, editing the Base style to explicitly set font traits to Regular got around the issue for me, so I'm not in urgent need of a fix.
  11. Yeah, as I mentioned in that comment, they aren't bold by default for me in a new document. This surprised me, as I had only really been working in the other one, but it makes sense.
  12. I think what the behavior should be if ToCs are supposed to be bold by default is that... 0. Instead of generating/updating a ToC applying direct "Font weight: Bold" to all entries when the Base style doesn't specify "Font traits"... 1. Generating a ToC should create a "TOC Main: Entry" style with "Font traits" or "Font weight" set to Bold. 2. This allows users to manage ToC boldness more intuitively, as they do with regular text flow. However, I find that if I make a new document, newly generated ToCs do not bold by default. In a new document, it's not even possible for me to set Base > Font traits > [No change] without changing the font family from the default. And when I do, newly generated ToCs still do not bold by default. So, I think this is just something that got weird in my doc, probably from importing a bunch of text from a Word docx. I noticed that did all kinds of weird stuff to formatting and styles until I cleaned it up. Thanks for trying things on your end, walt.
  13. You'd think so, but this happens even if I make a brand new spread and insert a ToC there. It even happens if I make the new spread with no master page. Since it's not happening for you, something must've just gotten confused in my document somewhere along the line. I'm typing up another comment with how I think it should work, but chances are it already works right for most people. My project is just very unique I guess!
  14. Just noticed this in the text styles panel (before I do the workaround). See the description section at the top of the panel: the bold is definitely being applied independently of paragraph and character styles. I'm assuming this is a default behavior of the ToC generator. It's worth noting that, in this case, none of the styles in the hierarchy (TOC Main: Heading 2, TOC Main: Entry, Base) have font traits set. So they're all just inheriting from some default. When I change Base to explicitly set font traits to Regular, the ToC styles begin to behave more like I expected. I don't even have to modify the ToC styles -- as soon as I update the ToC, all entries stop being bold unless I change a style to explicitly be bold.
  15. Thanks for experimenting, @walt.farrell. In my case, the text did not become un-bold at all. The only way I could un-bold it was by selecting the text within the text frame and clicking the B in the toolbar. (And then it became bold again the next time I update the ToC.) Paragraph styles had no effect on boldness, even if they affected other things (like which font, whether it's italic, or spacing). However, I decided to mess around with it more, and now, if I've set the style to normal weight, it un-bolds when I update the ToC! I'm not sure what changed in the meantime. I'm pretty sure I tried that before! (It still does not show the boldness change after clicking OK in the paragraph style editor. It only shows when I update the ToC.) At any rate, it's workaround-able for me now. I just have to update the ToC after changing the style. Not sure if I just never tried updating after changing the paragraph style, or if something else I did in the document un-stuck whatever was making the ToC bold things.

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.