Closed
Bug 90753
Opened 23 years ago
Closed 23 years ago
PDF incompletely loaded by Acrobat plug-in
Categories
(Core Graveyard :: Plug-ins, defect)
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.
Comment 6•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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?
Assignee | ||
Comment 10•23 years ago
|
||
If I remember correctly this is the default size which is used when dimensions
cannot for whatever reason be obtained.
Reporter | ||
Comment 11•23 years ago
|
||
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?
Assignee | ||
Comment 12•23 years ago
|
||
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
Reporter | ||
Comment 14•23 years ago
|
||
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.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•