Tizra / Tizra-Customer-Tracker

Bug/Enhancement tracking for Tizra publisher project
3 stars 0 forks source link

PDF Width not adjusting in ASPPA #128

Closed ghost closed 11 years ago

ghost commented 12 years ago

http://elibrary.asppa.org/erisa-outline-book-chapter-2/2

I have been going through the css for a while and I can't find anything on our end that is limiting the width of the PDF viewer and could really use help fixing this issue.

When I adjust the width in "Home > Presentation > Layout > Title Content" and adjust the "Page Content" layout block so that the width is equal to the width of our controls, it doesn't change.

When i do the same adjustment on http://omniplayground.tizrapublisher.com it works without an issue.

Please let me know if you see anything we have done to prevent the PDF from filling the 744px width that is set aside for the PDF or if this is a site specific bug that can be fixed.

Thanks.

daviddurand commented 12 years ago

I've been looking into this, in conjunction with #127.

I have some changes in place that may help, but I've got to make some tests, and document the new "right way" to do this, so the problem does not recur again. I know that in suggesting CSS previously, I did not offer any real guidance. Hang on for more info.

ghost commented 12 years ago

I really don't feel like these two things are related. I'm trying to adjust the width in the admin area of Tizra and I'm not using CSS to do that. This works on other sites, but not ASPPA.

This has more to do with https://github.com/Tizra/Tizra-Customer-Tracker/issues/100 where I'm trying to adjust the system settings and leaving the CSS alone.

In the previous bug report that I submitted I created a video to help show you what was going on. Please watch the video to see what I'm talking about versus what David is talking about. http://screencast.com/t/YmIOB41vEc

Thank you.

daviddurand commented 12 years ago

OK, this is an instance #100 which came up previously.

What is happening is that the block specifies a maximum width not to be exceeded, and otherwise it displays the document at a "natural size" based on the paper dimensions. This is particularly important as many PDF plugins now refuse to scale the document to fit the window, so if you look at that page in PDF mode in Chrome, you see a nice snug fit. (Unfortunately, that doesn't apply to every PDF plugin out there...)

You can force the size of the image, if you want, using the element with the id #t-page-image -- I did this on the staging site, to make sure it works, and to give you an example.

However, if the page size changes, the style can easily lead to distortion in image mode, as the page will be loaded in it's "natural size". In pdf mode, the size will just change the size of the box around the page (unless they have a properly installed Acrobat plugin). Because of this I still recommend adaptive layouts, or the new reader, rather than trying to jimmy the page block into a fixed slot, as variations in paper size (from poster to book), seem to be pretty common on your sites.

I am considering adding a force-to-size option to the page block, which could guarantee that the correct resolution of image is fetched, and would not make the situation with PDFs any worse than it is. In the meantime, you can look at what I did on ASPPA staging.

I suspect that distortion may actually be a problem on ASPPA, as I am assuming that the new document had a different paper size than the old ones (assuming that there are some pages where the width was what you wanted). You can use the staging site to try pages that came from different PDFs to see what happens with the CSS override.

daviddurand commented 12 years ago

Well, in both cases you are unhappy with the fact that the page block sets a maximum width, not an absolute width. Since it sets a maximum, making that maximum bigger than needed to fit the "natural size of the page" doesn't do anything. That's the way it works, and it's really convenient when you use a size like 10000 to mean "use whatever space you want," and totally useless in the quite rare case that you want to magnify a page. Since there are many sites with 10000 as a width or height, I can't just change what the block does. people with bad eyesight can just use the zoom reader, of course.

Right now, if you want to make a small page bigger in the page block viewer, you have to use stylesheets. That's just the way it is. I already know you don't like it, from #100. My copy of MS-Word makes me work really hard to do some things, but if I want to do them, that's what I have to do.

You could also use the zoom: stylesheet property to make the image the size you want without having any distortion happen, though you will still have to make sure that the pdf "paper size" for all documents on the site are the same, or else you'll have more size problems.

I'm considering adding something to set an absolute size, even though I think there are better alternatives, because I am in the middle of that code as part of the new reader setup -- but doing it in the middle of the revision creates problems.

On the bright side, the new markup enables links to work when viewing a PDF in image mode -- this might be something that customers like ASPPA might like (though they don't seem to have as many links as I'd expect).

I'm leaving this issue open as a task for enhancing the page block.

ghost commented 12 years ago

I can't use css to adjust the width because there are landscape and portrait pages. Because of this, setting a width and height would cause the landscape pages to be centered vertically with large black space on the top and bottom.

But, I now see what is going on with the page content block that I have been editing. When a page is narrower it can not exceed the zoom factor of 1 even though the settings in the system exceed that. So if that page at zoom of 1 is only 680 px wide, that is the space it will fill.

Experimenting with the zoom doesn't help either because I still run into the issue of having to support both the landscape and portrait page. A zoom of 1.2 may help the portrait page, but on a landscape page I still need to set some kind of max width and end up with the black bars on the page.

The only real work around for ASPPA would be to redo all of the PDF pages so that at minimum width is equivalent to an 8.5" page as a PDF before uploading. Then I can use the page content block to pick a maximum width for the PDF to appear on the page.

And to your point about being unhappy that it sets a maximum width isn't entirely true. I'm fine with there being a maximum because then I don't have to worry about landscape pages. But the problem for me is that the pages don't fill the maximum space, but in reality that would be a minimum width setting not a maximum. I don't necessarily think that an absolute width and height would be better because having some level of flexibility is valuable. I could work with David on coming up with a script to help determine what the width and height should be for a given page, but I am trying to reduce the amount of scripting we do on any given page to help keep performance as good as possible.

Thanks for your time on this, and please keep me in the loop with any changes you make to how the PDF width and height are set with the system.

daviddurand commented 12 years ago

I'm glad we're finally on the same page with this one. Here's what I was thinking might make sense. The new option would enable a "fixed" mode, but that would not really fix the page, but set a bounding box within which the page would be be fit. So it would never be bigger than the bounds you set, but if the document were smaller in one or the other dimension, it would be scaled up to the largest size possible.

So it would "fit width" or "fit height" depending on the shapes of the page and the box.

Now the other thing is that you can override the page format for the content page on a document by document basis, but that would be a pain and maintenance problem for most of your sites.

I think the bounding box idea actually meets the needs work, and I'll see if I can work it into the reader updates. Please don't just write a script for this layout problem, certainly without telling me -- too many support issues unless I at least know what's happening, and have a chance to warn you if it might eventually create problems.

It's the issue of changing page sizes that makes the obvious solutions fail in various cases.

If people didn't have completely unconstrained layouts with sizes like 10000x10000, a change would be a lot easier.

ghost commented 12 years ago

The important thing for us is being able to predict the width so the page looks correct. The height can be set with a maximum only because height doesn't have as many serious impacts to a layout as width does.

daviddurand commented 11 years ago

closing this old request as we are focusing on the new reading interface. Complex improvements like this to the current page content blocks will only come when we do a full overhaul of the templating system.