| Demonskunk |
I was wondering if you guys optimized the PDFs at all for reading using a device, or if you just use the same file as the print document, because when I try to read your Bestiary 3 PDF on my computer it runs really badly, and if I try to use Mac Preview, it runs all 8 of my cores at full power.
My computer is an up-spec'd early 2011 macbook pro with a quad core processor (with each core split into 2 virtual cores) and a Radeon 6750m graphics card. it should not be having trouble with a PDF.
Figured I'd ask, since your PDFs are (understandably) tamper-proof so I can't optimize it myself using Acrobat.
Vic Wertz
Chief Technical Officer
|
I was wondering if you guys optimized the PDFs at all for reading using a device, or if you just use the same file as the print document, because when I try to read your Bestiary 3 PDF on my computer it runs really badly, and if I try to use Mac Preview, it runs all 8 of my cores at full power.
My computer is an up-spec'd early 2011 macbook pro with a quad core processor (with each core split into 2 virtual cores) and a Radeon 6750m graphics card. it should not be having trouble with a PDF.
Figured I'd ask, since your PDFs are (understandably) tamper-proof so I can't optimize it myself using Acrobat.
It's not the same as the print document. (I won't say "optimized" because that's a technical term in PDF world that doesn't necessarily mean what many people think it means.)
We did hear that 10.7.x users were having problems like this until they installed the OS update that came out last week. Have you tried that?
| Demonskunk |
Demonskunk wrote:I was wondering if you guys optimized the PDFs at all for reading using a device, or if you just use the same file as the print document, because when I try to read your Bestiary 3 PDF on my computer it runs really badly, and if I try to use Mac Preview, it runs all 8 of my cores at full power.
My computer is an up-spec'd early 2011 macbook pro with a quad core processor (with each core split into 2 virtual cores) and a Radeon 6750m graphics card. it should not be having trouble with a PDF.
Figured I'd ask, since your PDFs are (understandably) tamper-proof so I can't optimize it myself using Acrobat.
It's not the same as the print document. (I won't say "optimized" because that's a technical term in PDF world that doesn't necessarily mean what many people think it means.)
We did hear that 10.7.x users were having problems like this until they installed the OS update that came out last week. Have you tried that?
No, I'll give it a shot though and let you know.
I was also wondering if maybe you guys could offer a smaller version of the download for E-readers? maybe something with lower res images and stuff? I bought a nook tablet almost specifically for reading PDFs, but some of the more image heavy ones run really slow.
| CountofUndolpho |
There is an epub version of the CRB PRD on the forums which works fine when converted to mobi for the Kindle - though it is a bit slow to navigate through the contents list.
The pdf's are going to be laggy whatever you do, they are just too rich for quick scrolling etc Drives me crazy especially on the rubbish little notebook I use when playing - toooooooooo sloooooooowww!
freeAgent
|
Have you guys checked what it would do the the PDF to strip out the background images on every page (the stuff that makes up the borders and such and prevents the background from being plain white)? If it helps the filesize and rendering performance a lot, it would definitely be an appreciated option.
| Chris Lambertz |
Have you guys checked what it would do the the PDF to strip out the background images on every page (the stuff that makes up the borders and such and prevents the background from being plain white)? If it helps the filesize and rendering performance a lot, it would definitely be an appreciated option.
We have discussed it a few times. This is still an in progress thing, but here's a thread with a fairly detailed description as to why it's more difficult than it would appear on the surface.
| CountofUndolpho |
freeAgent wrote:Have you guys checked what it would do the the PDF to strip out the background images on every page (the stuff that makes up the borders and such and prevents the background from being plain white)? If it helps the filesize and rendering performance a lot, it would definitely be an appreciated option.We have discussed it a few times. This is still an in progress thing, but here's a thread with a fairly detailed description as to why it's more difficult than it would appear on the surface.
When you are finally forced to admit to being in your forties one of the joys is presbyopia (all of a sudden you need reading glasses). One of the consequences of this is you come to loathe the tendency for all Rule books to suddenly have as much background clutter on the printed page as modern printing methods will allow! You may chuckle (if still enjoying youthful vigour) but one day you'll be blinking at small text on a patterned page trying to avoid the reflected light on it's glossy surface, thinking "bugger! I'm sure it should be +2 to AC!" Sigh
| Iron-Dice |
Here's a solution from another thread. Make preview run in 32 bit mode. It works like a champ. The issue is with OSX, not Paizo.
+
kwiqsilver wrote:
Does anyone know if there has been any progress on this issue?
Right click on Preview in the Applications folder then click on Get Info.
Click in the tick box for 'Open in 32-bit mode'.
And that's it. Solved the problem for me...
| CountofUndolpho |
Here's a solution from another thread. Make preview run in 32 bit mode. It works like a champ. The issue is with OSX, not Paizo.
+
kwiqsilver wrote:
Does anyone know if there has been any progress on this issue?Right click on Preview in the Applications folder then click on Get Info.
Click in the tick box for 'Open in 32-bit mode'.
And that's it. Solved the problem for me...
Does it work on middle age?
| Demonskunk |
Here's a solution from another thread. Make preview run in 32 bit mode. It works like a champ. The issue is with OSX, not Paizo.
+
kwiqsilver wrote:
Does anyone know if there has been any progress on this issue?Right click on Preview in the Applications folder then click on Get Info.
Click in the tick box for 'Open in 32-bit mode'.
And that's it. Solved the problem for me...
But running it in 32 bit mode would slow it down. 64 bit mode allows it to access more ram and therefore run better.
Vic Wertz
Chief Technical Officer
|
Iron-Dice wrote:But running it in 32 bit mode would slow it down. 64 bit mode allows it to access more ram and therefore run better.Here's a solution from another thread. Make preview run in 32 bit mode. It works like a champ. The issue is with OSX, not Paizo.
+
kwiqsilver wrote:
Does anyone know if there has been any progress on this issue?Right click on Preview in the Applications folder then click on Get Info.
Click in the tick box for 'Open in 32-bit mode'.
And that's it. Solved the problem for me...
The latest 10.7 update apparently fixed the problem with Preview and made this workaround unnecessary.
Talathel Noroviel
|
But running it in 32 bit mode would slow it down. 64 bit mode allows it to access more ram and therefore run better.
There's so many things wrong with this. First, the 32bit RAM boundary is at 2-3 GB: if your PDF viewer is using more than that much, there's a problem. I've only seen Preview gobble about 1GB maximum, and that's when I had a dozen Paizo PDFs open at once to test the performance in 10.7.3. Second, "more RAM" is not "run better" (let's disregard the extremely vague nature of the descriptor 'better'). There are so many ways and reasons applications can allocate memory. Merely being able to allocate more does not mean that a program will run faster. Using more memory can improve performance if the app is specifically written to use caching, but that is by no means automatic in any environment I've used (everything from oldschool C on Unix to C#, ObjC, and various dynamic languages). In fact, one sure sign of a bug is an application allocating a large amount of memory: this frequently suggests a memory leak. Third, the only real slowdown of launching an application in 32bit would be needing to seek the disk to load the 32bit libraries (as opposed to the 64bit ones which are in RAM because other apps are using them). If you've got other 32bit apps running, that initial launch slowdown probably won't exist. And let's not forget that in 64bit mode pointers are twice as big and so need more memory, thus actually defeating your point about more memory == better...
To summarize, your point seems to be a bit muddied by marketing hype. I hope I've dispelled it here.
The latest 10.7 update apparently fixed the problem with Preview and made this workaround unnecessary.
Yes, the 10.7.3 update fixed this (without any mention in the changelog, typical of Apple).
When you are finally forced to admit to being in your forties one of the joys is presbyopia (all of a sudden you need reading glasses).
Forties? Luxury! I've had glasses since I was 10. Could always be worse. ;)
| Demonskunk |
There's so many things wrong with this. First, the 32bit RAM boundary is at 2-3 GB: if your PDF viewer is using more than that much, there's a problem. I've only seen Preview gobble about 1GB maximum, and that's when I had a dozen Paizo PDFs open at once to test the performance in 10.7.3. Second, "more RAM" is not "run better" (let's disregard the extremely vague nature of the descriptor 'better'). There are so many ways and reasons applications can allocate memory. Merely being able to allocate more does not mean that a program will run faster. Using more memory can improve performance if the app is specifically written to use caching, but that is by no means automatic in any environment I've used (everything from oldschool C on Unix to C#, ObjC, and various dynamic languages). In fact, one sure sign of a bug is an application allocating a large amount of memory: this frequently suggests a memory leak. Third, the only real slowdown of launching an application in 32bit would be needing to seek the disk to load the 32bit libraries (as opposed to the 64bit ones which are in RAM because other apps are using them). If you've got other 32bit apps running, that initial launch slowdown probably won't exist. And let's not forget that in 64bit mode pointers are twice as big and so need more memory, thus actually defeating your point about more memory == better...To summarize, your point seems to be a bit muddied by marketing hype. I hope I've dispelled it here.
Ah. a lot of my gaming (non-tabletop) woes lately have been from steam not being 64 bit compliant lately, so I guess I've fallen into that. thanks for clearing that up