Jump to content

blw

Members
  • Content count

    36
  • Joined

  • Last visited

About blw

  • Rank
    Member

Profile Information

  • Location
    Richmond, VA, USA

Recent Profile Visitors

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

  1. One more update on this matter. I'm now on 206, and the behavior has improved still more. I was able to load the same large file, scroll happily through it up, down and backwards for the better part of an hour as I cleaned up some messy image outlines. This on my 16GB laptop. Memory allocated to Publisher never exceeded about 8GB until I had to do a full export. The full export still did not blow the size up past about 17.2GB, and while that did drive memory pressure far into the yellow zone and occasionally for brief moments into the red zone (as shown by Activity Monitor's Memory display), I was able to generate an entire PDF/x4 output file at full resolution. I think this is a bit bigger than Publisher really wants to do on this size system (my images are mostly 36- or 45-mp and there are lots of them), but given that I'm on the road and have only the laptop, this was more than satisfactory. And of course, closing the file after generating the PDF put memory right back down to the ~1.5GB level. I think this is very well resolved. I have been watching the various release notes and I haven't seen anything that corresponds to this, but the issue clearly has received developer attention and now works as well as can reasonably be expected given that I was putting six pounds in a five pound sack.
  2. > See: Affinity Publisher Beta Help > Publishing and Sharing > PDF Publishing > Publishing PDF Files: Oh. Maybe then I mean better indexing. I looked for export - which of course is the command involved.
  3. Useful information, thanks. (It ought to be in the help somewhere!)
  4. Is there any documentation on the various export options? I'm specifically interested in the PDF options. I don't generally look at the PDF that's generated, but when I generate PDF for web, I get a 45MB file. It pixelizes badly, which I am not too surprised at given 45MB and 300 images. On the other hand, if I export "for export" I get a 950MB file. I can guess that this simply takes all of the files at maximum resolution. But what about PDF/x4, which presumably is intended to go to print? It's 68MB, although "export for print" yields 170MB. I have done a reasonable amount of due diligence - export doesn't yield anything in Help->Publisher Help, and the google hits on this turn up mostly in foreign languages and don't appear to be too relevant to publisher. I'm on the latest .174 on a Mac running Mojave.
  5. I think it depends on what sort of book you're doing. In this context, I am doing picture books for race teams, so my books are loaded with "resources." In my day job as a mild-mannered computer scientist, both of my books have a few screen snaps in them, but virtually all of the content is text, equations or a few diagrams. With that kind of book, I don't remember needing a resource list at all.
  6. This isn't a bug, in the sense that I'm sure that the code is doing as designed... but these two usability problems are getting fairly close to bugs! Fortunately I don't think they're hard to fix. One problem is that there is no convenient way to generate a machine-readable list of resources from the resource manager. About the only way to use it is to view it on the screen. I've had to resort to making multiple screen snaps, but I wouldn't really call that "usable." In my case I have to send copies of this to the photo department to get updated or edited copies of files that were used. I'd really like it if there were an "export" button or similar that produced a .txt or .csv file of the resources used, in the order presented in the resource manager display. I'm pretty certain that this is general to both Mac and Windows (and Linux?) versions. On a related note, at least on my Mac, the resource manager window disappears or hides when I click on something else. So for example, if I want to send an email to one of the photographers to get me a new copy of X, Y and Z, I would bring up the mail program - which instantly causes the resource manager window to disappear! Aaarrrrggghhhh!!! I worked around it by popping up the resource manager, taking a screen shot of it, and then leaving THAT on the screen whilst I sent the email... If it would just stay visible... I'm on a Mac running Mojave (10.14.1), with 40GB memory.
  7. I did look in the release notes for a fix that I thought corresponded, but I agree that I don't see anything that specifically fixes it. However, I'm pretty certain that there is *something* different, as noted I had Publisher up to 33GB on a reasonably routine basis using the 40GB system. Perhaps the fix was really done somewhere else and this is a pleasant side effect.
  8. It's set to 40GB, the same size as physical RAM on the system. I'll assume that it has always been set this way as I didn't know it was there.
  9. In the intervening couple of weeks, I've upgraded to .162 and things appear to be quite different now. Although scrolling from newly loaded file does grow the memory size, it now grows only so far and then stops growing. I can't get my file to exceed 22GB now, even on my 40GB system - even though the file is now materially larger than it was back when I reported the bug. I've been scrolling back and forth all day and it's still sitting at about 21GB. Previously this would just go much further (over 33GB as previously noted). Something's been fixed, although I don't see a reference to such a thing in the release notes.
  10. Well, I did say in my original note that it felt like cockpit error. However, I really don't see the little control widget when I select the picture frame. I've attached a screen snap from when I have a picture frame selected, and unless I'm looking in the wrong place, I don't think I have that control visible. Hmm... it says "there was a problem uploading the file... 200."
  11. I seem to be having trouble with getting allowed to edit / move / resize images in picture frames, and from some discussion elsewhere it appears that this may be a Mac-only issue. I'm running Publisher .162 on Mojave on an iMac 17,1 with 40GB memory.
  12. That kind of does what I want. It does allow me to move the image around. However, I'm a bit surprised that it doesn't bring up that little control set. Seems like clicking on the frame should do that?
  13. I am pretty sure that this is 100% cockpit error, but I've done my due diligence with Google and Help... When I create a picture frame and then drop an image into it, I usually (nearly always, but not always) have the opportunity to resize or move the image within the frame. There is an icon somewhere on the screen that looks like a Play button, a slider, and some other stuff. How do I get this control back once I've left the picture frame? I know that occasionally I can stumble around and get it to appear. But most times I can't figure out how to get it back. This has dogged me since 1.7.0.58, and I'm now on .162 - and while I'm on a Mac, as I said, I suspect that this is user error...
  14. Chris, the file I uploaded about the memory consumption issue is the same one as produced this issue. It still does this in 1.7.0.145, so you might want to have a look at this one too.
  15. Unfortunately not. I tried that immediately. I really do wish I could capture a crash dump as I historically have done on every Unix system previous to the Mac... [Googles...] OK, now I know about lldb, so I'll enable that from now on. I am moderately sure that the one I deleted is a variant of what's on page 69 of the file uploaded in my Memory Consumption thread. From what I remember, I had exported that PDF with the wrong fonts - probably it was whatever OpenOffice defaults to (TimesRoman?). So I deleted the placed PDF and it crashed. I then fixed the font in OO, then exported it again and placed it as you see it. It's possible it happened on page 68 instead, but probably it was 69.
×