search

Tizra / Tizra-Customer-Tracker

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

IE7 and IE8 have link display problems on page images #197

Closed ghost closed 11 years ago

ghost commented 11 years ago

http://screencast.com/t/pomvu5EVUghK

http://screencast.com/t/8kwRruyEI

My contact at ASPPA informed me that links were not showing up in Safari and IE8. I started by checking Safari and noticed a couple things.

In safari you don't allow a PDF to show. The only option is an image. Because you only allow an image we need the cross linking of ASPPA's site to work correctly. If you look at the first supplied screen shot you will notice that the image scales down and seems to get a margin included in it that isn't in the PDF. This causes the text on the image to shift and the links to get misaligned. You should also notice that in chrome the PDF is lined up properly, but even the image in chrome scales and shifts essentially making the links useless.

I tested the same document out in the new reader and the same problem exists (second screencast). Links don't line up correctly.

I have checked to see if I adjust any sizing of the PDF or Image with CSS but haven't been able to find anything that I have done that impacts the viewer.

I need this working correctly as soon as possible.

daviddurand commented 11 years ago

This is caused by the PDF -- and is quite rare, as the link scaling has been done the same way for months now. My guess is that the crop box for the PDF is different from the media box, and/or the trim box, and that is causing the problem.

ghost commented 11 years ago

I checked the PDF and it looks like all of the "boxes" are the same dimensions. 7.25x10

I'll try to get you a sample of chapter 1a

daviddurand commented 11 years ago

I just opened it, and the "media box" is 8.5"x11" -- something that my version of Acrobat only shows when I inspect the internals of the PDF with the Preflight tool.

Interestingly when I look at the "Set Page Boxes" tool, it shows two rectangles, but says that they are the same dimensions.

Looking at the internals of the PDF, you get MediaBox 8.5"x11", and all the others are 7.25"x10".

Sorry the display is in points: (https://f.cloud.github.com/assets/1316941/281770/7dc62c4a-917f-11e2-9010-00c3461e67bb.png) Here's what things look like in the "Set boxes tool" confusing because they display a different size than they show in the dialog. Also interesting is that the inspector above shows the 3 boxes that I know from the code: media box, crop box, and trim box. The Acrobat dialog is in terms of the "art box", "crop box", "trim box" and "bleed box". Acrobat won't let me change the page size, which seems like the likeliest fix to me.

Here's how it shows all boxes: (https://f.cloud.github.com/assets/1316941/281794/0f68f916-9180-11e2-973f-305efbef5bec.png) and here is looking at two of the four options (art, trim, crop, bleed). The trim and crop boxes are the same, as are the art and bleed boxes:

(https://f.cloud.github.com/assets/1316941/281803/33609eaa-9180-11e2-8fd5-3d44604b7c90.png) (https://f.cloud.github.com/assets/1316941/281805/35ca61da-9180-11e2-81c4-c91f6247aae3.png) I think the upshot is that you should try regenerating the PDF with a custom page size and no cropping and see if that works.

ghost commented 11 years ago

I actually was just working on reprinting the file as 7.25x10 to see if that fixed the issue. I noticed the the odd rectangle within our crop tools too and it looks like we have both come to the same conclusion that reprinting/reprocessing them at the preferred page size might work. Only issue is that all of the bookmarks and links get taken out when I reprint. Not a gigantic problem because I have a way to get them back in, but I'm a little concerned that the links won't line up correctly when I do it.

I'll see how it goes.

daviddurand commented 11 years ago

I was able to remove all the cropping boxes (by setting margins to zero everywhere in Acrobat). The pages come out larger because they include the margin, but the links line up properly. The extra margin does not look bad in the new reader, but will probably look funny in your custom page design. But it's a fallback option, anyway.

I also noticed that the links are URL links to pages on the web site. That works for online reading, but not so well I don't know if WP has a way to output links to PDF, but with the MS-word feature, we can automatically translate internal word links (that become internal PDF page links), into the appropriate web links when we publish. They remain internal PDF links in excepts and other downloads, rather than going to the web site. This may be something you want to explore next year...

ghost commented 11 years ago

All those links are manually added to the pdfs. I can't use your new reader for ASPPA because they are already pissed that copying text out is clunky and doesn't keep formatting. Since the extracted text doesn't keep any formatting at all it would only further irritate them if we switched to your new reader. Since I have to use the original reader I have to crop the margins because we received complaints that the text was too small. With all that in mind, your fix won't work for this project.

I'll continue to try things out on my side.

ghost commented 11 years ago

Is there any way that you can use the crop box rather than the media box for your images?

daviddurand commented 11 years ago

That all makes sense to me -- that's why I thought that it's at best a fallback in case you get stuck and need to get something live quickly. If the PDF conversion takes too much time, it might even make sense to re-work the reading layout so that the margins don't shrink the text so much.

I will investigate if I can make the current document links work properly without breaking the thousands of documents that are working properly. Since most of them are not generated from WordPerfect, they are apparently making different use of PDF features

I know that production of this document is a fundamental part of the problem. If at any point you guys are interested in exploring an HTML-based or XML-based solution again, that may be the best approach long term. I don't know what their commitment is to print editions, compatible pagination, etc, either. Even if those were not issues, it would of course have some costs in time and money.

As time goes on, the chance that those kinds of capabilities will be added to the platform anyway is steadily going up, but there are no schedules or commitments as of yet. So at some point there may be other options.

daviddurand commented 11 years ago

As to the crop and media box question, the images are generated by a package that we use, and the problem is not the image that is generated (you were able to get the right image), but making sure that we are calculating the right scaling factors and margin offsets, when the page size varies in this way. Since there is built-in logic in the rendering package that we use, we have to match that logic for the image margins and scaling, since we have to calculate the links from PDF source coordinates and the pixel dimensions of the final rendered page. We do use the sizes and offsets of the crop and trim boxes in that calculation.

The reason I'm not just promising that I can fix this quickly is that we have seen many different PDF files with different settings, and fixing the code so that one works frequently breaks the other. To my knowledge, what we have now is working for all live content across all publishers, except for this document, so if there is a quick production fix, that will be a good thing. Based on past experience, it could take quite some time to figure out what exactly is leading to the scaling problem in this case. As I said, I will be looking into that, however.

I'm reopening this, so that I can close this if I can find a solution for this document, but I'm hoping that you may find a way at your end, as it may be involved.

ghost commented 11 years ago

I'm testing out exporting the links and then importing them into a reprinted file at the correct size. I think I can shift the location of the link consistently and get them to land at the right spot, but it will take a while to test.

ghost commented 11 years ago

OK, I think reprinting everything to 7.25x10 and then importing all the links and bookmarks will work. My test of Chapter 1A worked well and now all the links are in the correct place for chrome and Safari.

daviddurand commented 11 years ago

great. I'll close this once I can figure out either how to fix the wordperfect-created pdf files, or determine that it can't be fixed and keep the rest of the more common pdfs working.

ghost commented 11 years ago

So, I have all the files updated and it is now working correctly in Safari and Chrome.

When I checked it in IE9 it didn't work. The links do not appear at all even though they are in the markup.

Do you have an example of a site that you have this setup for one of your customers so I can look through the css and see if there is something that I'm doing that you are not?

ghost commented 11 years ago

I checked this in IE8 and IE7 and they all seem to function the same way. The links show up in the markup, but don't work in the UI.

daviddurand commented 11 years ago

Try this test document: http://david.hub.agilepdf.com/2uqujp/7

I'm accessing it with IE9 without trouble, and in IE8 mode in IE9 without trouble.

I did see some trouble with IE7 mode -- which is a little behind the curve, but should probably work, and I have a fix that I can make live within an hour.

I don't know if I'll have to downgrade IE to test the old versions, but let me know what you are seeing first.

ghost commented 11 years ago

It works correctly in the new reader, it doesn't work correctly in the old reader.

I'm going to see what I can figure out with the css.

daviddurand commented 11 years ago

I've been looking at it, and it seems that IE7 wants actual text in order for the link to be active. I put a nonbreaking space in, and that works, but it's very narrow -- you have to mouse over the very left of the link.

I also saw that the old reader was not getting a required background to make the link active in IE8 -- fix not yet live, but coming. The only problem I can't yet solve is IE7. It seems to be due to IE7 making children inherit z-index from their parent (which is making the next/previous page links overlap the document links, even though the document links are z-index 15000, and the next/prev are 500...

I think I can fix it, but it will require some care.

Will push the IE8 fixes shortly.

daviddurand commented 11 years ago

You may have to refresh your cache, but the new stylesheets are now in place, and it should be working with IE7-IE9 in the old view.

I'm still dealing with IE7 links for the new reader. IE7 and earlier have a unique interpretation of z-index, that makes it useless unless you do backflips.... what a surprise.

ghost commented 11 years ago

I see your fix in place. I'm getting some weird IE behavior when I don't have the document mode and browser mode on the same version of IE. There may not be anything that can be done about it.

Thanks for digging into this, I keep getting other things that I need to fix or look at and haven't had time this morning to dig into the css the way I wanted to.

daviddurand commented 11 years ago

The current fixes seem to work reliably, at least in IE9 in IE7 and IE8 mode. You may have to aggressively flush caches to see the current versions.

The new reader uses layers to put links on top of the next/previous page links. This can't be made to work in IE7, and until we totally drop IE7, we are using a CSS hack that makes the page navigation links smaller in IE7 and below (10% of total window width). This should leave all text links functional, except for the theoretical case of tiny links in the margin when the user is viewing the file in a small window.