Closed Bug 90753 Opened 23 years ago Closed 23 years ago

PDF incompletely loaded by Acrobat plug-in

Categories

(Core Graveyard :: Plug-ins, defect)

PowerPC
Mac System 9.x
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: bugmail, Assigned: serhunt)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010629 BuildID: 2001062823 In the attached example, the PDF file embedded as an object does not completely load and is displayed, by default, in odd and small (for the example PDF) dimensions. Reproducible: Always Steps to Reproduce: 1. Access the attached HTML file using Mozilla Actual Results: Nothing is displayed. It seems partial display can be coerced by clicking on an OS menu heading, though such display is fleeting at best. Expected Results: The embedded PDF file should have been displayed, and in its' intrinsic dimensions since none are specified. This may possibly pertain to bug 89891.
What should it look like? I think HTML should specify size in cases like this because there is no such thing as an intrincic size, unlike say when we do images and the size comes to us in the data stream. Or, please educate me here. Adding Liz.
Adding CSS to the OBJECT in question (better than HTML HEIGHT and WIDTH) does cause the PDF to resize, though display is no more complete than before. For the specific PDF in question, add CSS of "width: 16.86in; height: 21.26in". Of course, this bug has two parts: (1) incomplete display, and (2) how optimally to display PDF without any explicit dimensions in CSS or HTML. (1) needs some investigation. (2) could use some insight from someone intimiately aquainted with the PDF plug-in on what data is available. When an OBJECT is loaded, for example, there must be at least some mechanism for it being "replaced" with itself in the proper dimensions; it works for bitmap images, for example GIF, JPEG and PNG. Isn't there some way OBJECTs can generically determine the replaced dimensions and apply them in lieu of explicitly specified dimensions? This would seem to be the optimum solution for default display. (As an aside, I've always been interested in finding out if there are additional controls available in the plug-in to control embedded PDF display via such extension mechanisms as PARAMs.)
To answer your question better, though, PDFs *do* have an intrinsic size. Open one up in Acrobat Reader. The intrinsic dimensions are displayed right there at the bottom of the window.
Keywords: testcase
Keywords: acrobat
Reporter: Please try with a more recent build. I think the build you are using, 2001062823, may have problems with PDF as there were many checkins around that time.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I retested using build 2001071309 and the PDF displayed completely, though somewhat sluggishly; the HTML loaded and the Acrobat application launched, and then Mozilla seemed to take a few seconds before displaying the PDF. So part 1 of this bug seems to have been fixed. Part 2, though is still evident. Somehow Mozilla is still assigning arbitrary dimensions of approximately 240px wide by 200px high to this object. It seems as though Mozilla should be able to determine the intrinsic dimensions of the PDF and assign them to the replaced content.
Resolving as WORKSFORME based on last comment and my own testing. Some observations: 1) Win32 IE 5.5 doesn't even display your testcase at all 2) Nav 4.x displays the ALT text and looks like it even shrinks it smaller than 240x200 3) Nav 6.1 displays it fine and it didn't seem that slow in comparison to IE which looked like it was downloading the whole file, but didn't display when done. The PDF is close to being one meg. >(2) could use some insight from someone intimiately aquainted with the PDF >plug-in on what data is available. When an OBJECT is loaded, for example, there >must be at least some mechanism for it being "replaced" with itself in the >proper dimensions; it works for bitmap images, for example GIF, JPEG and PNG. >Isn't there some way OBJECTs can generically determine the replaced dimensions >and apply them in lieu of explicitly specified dimensions? This would seem to >be the optimum solution for default display. Your are sort of right. The OBJECT element's (and almost any container for that matter) size can be changed from layout without any problems. However, what size would we change it to? How would we know what size, how would we get that value? According to the Plugin API, I don't believe there is a direct way that a plugin can communicate it's desired size back to the browser, unless I think it was desgined to be windowless. However, if a plugin wanted to apply an "intrinsic" size, I believe in embedded mode, it could. The plugin knows what size and where it REALLY is by the SetWindow() call. The plugin also knows the attributes of the tag. Using some fancy Javascript, the plugin could possibly change it's size through the DOM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Thanks for the response, Peter. With respect to issue 2, it sounds like the Acrobat plug-in itself would need to be revised to itself cause the PDF to display in the proper dimensions. Is the plug-in responsible for arbitrarily choosing the approximate 240x200 dimensions being used presently, or is this something assumed by the OBJECT handler in Mozilla?
If I remember correctly this is the default size which is used when dimensions cannot for whatever reason be obtained.
Are these dimensions also used when an IFRAME document doesn't specify dimensions? (e.g., "http://www.tcp.com/~greg/mozilla/object/indexBackground/", and presumably this would happen with a text/plain or text/html OBJECT as well, though that's as yet not implemented; see bug 678.) Is there perhaps a better fallback position for display dimensions in such cases?
Don't know about IFrame but object frame uses it locally. The code is here: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsObjectFrame.cpp#6 35
v
Status: RESOLVED → VERIFIED
After trying the testcase again under 0.9.3, I still see that the PDF loads and displays properly, but is a bit misleading. The document loads and declares, "Docuement: Done," but nothing happens; it seems the PDF is, in fact, still being downloaded in the background, and takes about 30 seconds to finish. It is, indeed, a large PDF. It would seem appropriate to give the user some indication that content is still being loaded.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: