|
I've done this before (but not for any of my PFRPG PDFs). I'm interested in knowing if you find a better way to do it; because mine involves:
1. Selecting all the text in the pdf page-by-page.
2. Copying it into MS Word.
3. Reformatting everything in MS Word.
4. Re-making all of the tables in MS Word manually.
Its a process I chip away at slowly for a few weeks, and all in all probably takes me 45 hours of work. I've sped up the process a bit by getting really good at using find-and-replace in MS Word in clever ways to save time, but its still a long and tedious process.
Example: Somewhere I have a massive word document that collects every spell printed in a Forgotten Realms book for 3.0/3.5. That took me a very long time, and I dont believe I ever finished it - the goal was to cut down on the number of hardcover books I was dragging across town with a bicycle+backpack. (I'm not even sure I remember where the file is, las time I used it was 2+ years ago).
|
|
Found a PDF reader for Android that lets me have it not load images. Made things a lot faster, but a lot less pretty. Would still love just a regular one optimized for mobiles/netbooks.
It's APV PDF Viewer if anyone else is needing something for Android.
Hmm. Handy. My way offers a prettier solution (and you can add the errata in fairly easily), but as I mentioned, the initial PDF to add the errata to is a fairly large task.
|
While I love Pazio PDF's. The recent Tomb of Horrors PDF shows a large file can still operate very smoothly on my iPad.
It renders super fast when flipping from page to page.
Is it the color that makes them operate less smoothly. Not sure but I doubt it. It's probably the layers.
The PDF's are still useable but was amazed the the rendering did happen, for the Tomb of Horrors, much faster to the point of not noticing it on the iPad. So maybe something could be done by Pazio for it's PDF's.
I have always been one who didn't care about it and thought people were just winning on these threads but seeing that huge file operate the way it did I am starting to lean the other way.
|
While I love Pazio PDF's. The recent Tomb of Horrors PDF shows a large file can still operate very smoothly on my iPad.
It renders super fast when flipping from page to page.
Is it the color that makes them operate less smoothly. Not sure but I doubt it. It's probably the layers.
The PDF's are still useable but was amazed the the rendering did happen, for the Tomb of Horrors, much faster to the point of not noticing it on the iPad. So maybe something could be done by Pazio for it's PDF's.
I have always been one who didn't care about it and thought people were just winning on these threads but seeing that huge file operate the way it did I am starting to lean the other way.
Good to know. I have been tempted to put it on mine.
|
|
I have an Acer Iconia A500 tablet running Android 3.1 using ezPDF Reader and I have 0 problems with Paizo PDFs. I think the worst load time was 5 seconds and that really only happens when trying to flip pages really fast (in general when doing that I just grab the page I want to use from the selector at the bottom, much quicker).
So while yes the PDFs are a little large, they work perfectly well with mobile devices without any real need for change.
|
|
I have an Acer Iconia A500 tablet running Android 3.1 using ezPDF Reader and I have 0 problems with Paizo PDFs. I think the worst load time was 5 seconds and that really only happens when trying to flip pages really fast (in general when doing that I just grab the page I want to use from the selector at the bottom, much quicker).
So while yes the PDFs are a little large, they work perfectly well with mobile devices without any real need for change.
Yea that is about the time for my iPad...which is more than with the Tomb of Horrors....so I was just looking for that.
Its great they work for you and like I said they use to work for me until I saw how fast it is with the incredible large file of the Tomb of Horrors.
Plus if it was perfect you wouldn't be able to pull up all the requests for this very thing on these forums that I use to say the same thing you did.
My ASUS Transformer does chug with the PDFs, if it loaded them faster I'd stop carrying physical sourcebooks to gaming sessions and remove some of the inevitable clutter at the gametable. I'm gonna give ezPDF Reader and APV PDF Viewer a try and see if they work a little better than the stock Adobe Reader that comes with the tablet.
Slow day at work, threw APV PDF Viewer on the tablet. I'm totally agreeing with ArcSyn now, disabling images works wonders for the load speeds on the files.
I'm not entirely familiar with creating PDFs, but it seems like the Pathfinder Core, APG, and other books I've purchased have the images in layers, with the text overtop. Putting these books, either the single-file or by-chapter versions, on a mobile device like an Android or Nook Color makes them nearly impossibly slow to use. Even my netbook takes a few seconds to render a page with images. I love that they are of extremely high quality, but I'd love to use them more speedily on my mobile devices.
Is there some way to create a lightweight version of the PDFs that have all the images flattened to one layer, or optimized in some way for mobile devices?
I've been converting the files into black and white, single layer PDFs through some software at my office. Inelegant and ugly, but even my desktop computer has significant load times on the stock PDFs. I would love if Paizo was able to flatten the PDFs prior to watermarking. That alone would significantly help the load times.
|
|
I've been converting the files into black and white, single layer PDFs through some software at my office. Inelegant and ugly, but even my desktop computer has significant load times on the stock PDFs. I would love if Paizo was able to flatten the PDFs prior to watermarking. That alone would significantly help the load times.
Food for thought: That might exponentially increase filesize.
If they only have a single layer of images, then instead of a single background (or two, one for left pages, and one for right), you'd have a separate image for each page even though the images would be 75% the same as the last page.
Likewise for reused table backgrounds.
So that 9MB file? Now its 60+MB.
It would be worth the effort to have them condense the background layer into a single image though.
Now, they could offer printer-friendly PDFs, with no page backgrounds, and little for tables as well. Those would render nicely on your handhelds and older PCs. Hell, it would save me the trouble of making it myself in MS Word (for the books I bother to do it with).
Alternately, they could switch everything but character art over to vector graphics. You'd likely have slightly less ornate backgrounds (unless they put more work into making them), but the filesize and loadtimes would be much much much much faster.
| 2 people marked this as a favorite. |
This has been addressed a few times before in few different threads. We are looking into different ways to provide our PDFs in a way that's more screen-friendly, however, there are no definite plans.
Darkholme brings up some good points as to why this hasn't been done yet, however. So, I will explain a bit about why we aren't doing it now:
If we're only talking "background" elements like header graphics, footer graphics and the background texture, this brings up the following problem: some images we use are located above the background texture, but below the header/footer graphics. So you would end up with "funky" spreads where an image lays on top of the header.
This is quite time intensive and there is no way in InDesign to export all images flattened without flattening the text. This also opens a door for a number of potential errors if we were to attempt the above routes. Additionally, if we went with the first option, and created an in-document toggle for the background (say, a button), it would not work on the devices we'd want it to work for. Currently, interactive elements that toggle images or layers on and off are exclusive to desktop programs like Adobe Reader. This also wouldn't solve the problem that the file size would be the same, regardless of toggling.
We do not export any PDFs with Acrobat layers, so every element is actually on the same "layer." The reason you're able to select individual elements has to do with layer flattening. If the entire document were to be flattened, the text would be included. Rasterized text cannot be searched, selected or easily made into links.
As for converting to vector graphics: a lot of the elements we use actually are vectors, and they actually end up making the file size larger than if they were in a rasterized format. This has to do with the amount of points contained in the vector, and any effects that are added (like drop shadow).
When we're talking about large documents (like Tomb of Horrors) the reason you don't find that it bogs down your reader is most likely due to the absence of any color images and the amount of elements on each page. However, this is reflective of the approach to the book, which is quite large. When you have a large book like that, the approach they took makes a lot of sense.
While the above sounds quite negative, it's only to help explain why it's taking a while. We're still chugging along and seeing what we can do, because this issue does come up frequently.
|
|
| 1 person marked this as a favorite. |
Chris,
Thanks for pointing out this post in another thread.
This sort of technical explanation is probably more than most readers wish to know, but for those who are interested in the whys and wherefore, it is an excellent and insightful post. Thanks for this one.
This has been addressed a few times before in few different threads. We are looking into different ways to provide our PDFs in a way that's more screen-friendly, however, there are no definite plans.
What about simply leaving out the window dressing? How much could be gained by just leaving out the background image, and how easily could this be accomplished?
My PC doesn't care (and, indeed, being the cocky braggart he is, he tells me to ask you for more background images), but those netbooks and tablet PCs (and, indeed, phones) have a less cavalier attitude about documents that require a lot of processor brawn.
| 3 people marked this as a favorite. |
A version that was streamed out with rasterized low-DPI backgrounds/internal art would be awesome, even if we have to wait for production of the next printing of Core/APG (so that the graphic designer work can be streamed into a higher-profit activity). The other books.... are a much tougher sell to Paizo, especially with the reprint policies they have in place. (PDFs are different, but designer time is generally more expensive than writer time).
What about simply leaving out the window dressing? How much could be gained by just leaving out the background image, and how easily could this be accomplished?
My PC doesn't care (and, indeed, being the cocky braggart he is, he tells me to ask you for more background images), but those netbooks and tablet PCs (and, indeed, phones) have a less cavalier attitude about documents that require a lot of processor brawn.
It's a matter of creating a process that is work-flow friendly for Paizo, also. I won't go into the specifics of how we work, but there are some challenges with making sure the working files aren't compromised when we're getting them ready to be exported as PDF products. Human error can be a detriment and increase time spent on a product. I'd also like to point out that it isn't just a matter of removing background images. Text styles and colors would also need to change. Making a screen friendly PDF simply by stripping out "unnecessary" elements is going to leave you with a funky looking product.
Given that it is my job to export, optimize and refine the electronic products (PDFs and ePubs) that Paizo produces, I can assure you that this is an honest assertion. It is one of my priorities to find a solution that works for customers that want screen friendly PDFs, but it has to work for Paizo internally and be an efficient process in order to be viable.
Senior Software Developer
|
| 2 people marked this as a favorite. |
Having been in the publishing industry for over two decades, been responsible for designing and supporting production workflows for multiple newspapers, having run a software company and been responsible for adopting source control and automated build processes targeting multiple platforms, I am well aware of what is theoretically possible with "just bits"... and what is actually possible in a real-world environment even when you have 100% control over every phase of the process.
My guess is that Paizo's workflow is simultaneously far less sophisticated than what people may be picturing, and yet is probably more sophisticated than most other companies operating in this market. We're always looking to improve our processes, and in fact as Chris points out above, that's basically her entire job. Doing what people are suggesting would probably require a couple more hires and potentially a lot of custom software.
Not that we'll never do it, but the reality is more complicated than what you'd think at first glance.
|
Chief Technical Officer
|
Even more technical critique of production process: At a hand-waving-explanation level, PDF is a file format that creates a program that draws the image you want to see on the screen. It is designed to have all of your repeated-stuff come in before the first time you show it, so that it can effectively display over the internet as soon as the first full page can be drawn.
That's not quite accurate—at least, not always. One of the options in the PDF format is called Fast Web View. With Fast Web View on, all of the elements included on any given page are included within the context of that page. So if you open a 40-page PDF over the internet, and tell your browser to jump to page 30, it's able to quickly download all of the stuff that gets displayed on page 30, and can quickly display that page without having to wait for elements that aren't on that page to download. The downside is that repeated elements are included within the file multiple times, so the complete file is usually larger than if it had Fast Web View off (and in the case of documents with a lot of repeated elements, it's usually *much* larger).
With Fast Web View off, the repeated elements are included in the file just once (as you describe) so the file is smaller, but, viewed over the internet, the browser will usually end up downloading more than it really needs to before it can display a specific page, so you'll probably wait longer before your page is drawn.
When you're viewing a locally stored PDF on a device with sufficient RAM to store the entire document in memory, Fast Web View doesn't speed up rendering time in any significant way—but the file bloat that Fast Web View causes results in the document using more RAM than it probably would with Fast Web View off. (Because we distribute our PDFs zipped as opposed to loading them page-by-page over the internet, Fast Web View is generally not desirable for us.)
A version that was streamed out with rasterized low-DPI backgrounds/internal art would be awesome, even if we have to wait for production of the next printing of Core/APG (so that the graphic designer work can be streamed into a higher-profit activity). The other books.... are a much tougher sell to Paizo, especially with the reprint policies they have in place. (PDFs are different, but designer time is generally more expensive than writer time).What about simply leaving out the window dressing? How much could be gained by just leaving out the background image, and how easily could this be accomplished?
My PC doesn't care (and, indeed, being the cocky braggart he is, he tells me to ask you for more background images), but those netbooks and tablet PCs (and, indeed, phones) have a less cavalier attitude about documents that require a lot of processor brawn.
It's a matter of creating a process that is work-flow friendly for Paizo, also. I won't go into the specifics of how we work, but there are some challenges with making sure the working files aren't compromised when we're getting them ready to be exported as PDF products. Human error can be a detriment and increase time spent on a product. I'd also like to point out that it isn't just a matter of removing background images. Text styles and colors would also need to change. Making a screen friendly PDF simply by stripping out "unnecessary" elements is going to leave you with a funky looking product.
Given that it is my job to export, optimize and refine the electronic products (PDFs and ePubs) that Paizo produces, I can assure you that this is an honest assertion. It is one of my priorities to find a solution that works for customers that want screen friendly PDFs, but it has to work for Paizo internally and be an efficient process in order to be viable.
Can't you just make a button you click on that makes it screen/mobile device friendly? ;P
That has always been my favourite request when it comes to software. "Just put a button there that you push and it (does whatever feature they are requesting.)" Doesn't matter what it is, or how much actual input from a human being the whole thing needs. There should be a button that does it all.
But I have to say that the guy (it was usually the same guy) always understood when we told him that the process can't quite work that way.