By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,760 Members | 1,585 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,760 IT Pros & Developers. It's quick & easy.

Basic Question

P: n/a
How do I add a link to download a *.pdf file in Dreamweaver? I admit
I'm not very savvy with this and usually just do a cut and paste from a
*.doc document. I inherited this from someone who set up the website.
Any help would *greatly* be appreciated!!!

Thanks!

Mar 24 '06 #1
Share this Question
Share on Google+
19 Replies


P: n/a
landingone wrote:
How do I add a link to download a *.pdf file in Dreamweaver?


<a href="example.pdf">Foo</a> - just like any other link.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Mar 24 '06 #2

P: n/a
David Dorward wrote:
How do I add a link to download a *.pdf file in Dreamweaver?


<a href="example.pdf">Foo</a> - just like any other link.


I suppose the OP wanted to know about some wysiwyg way that does not
require typing HTML markup, which is soooo difficult. (Admittedly, the
<a> element is really monstrous jargon. It should have been something
like <link ref="...">...</link>. Who would _guess_ that "a" means
"anchor" and "anchor" means "link"?)

But perhaps most importantly, a link to a PDF file should always be
a) accompanied with a link to equivalent content in a more accessible
format, such as HTML
b) explicitly indicated as a link to a PDF file, minimally with the note
"(PDF)" after it
Mar 24 '06 #3

P: n/a

Jukka K. Korpela wrote:
I suppose the OP wanted to know about some wysiwyg way that does not
require typing HTML markup, which is soooo difficult.


Don't be so offensively patronising to _every_ post. Some posters
deserve this, most don't.

Mar 24 '06 #4

P: n/a
Greetings.

In article <e0*******************@news.demon.co.uk>, David Dorward wrote:
landingone wrote:
How do I add a link to download a *.pdf file in Dreamweaver?


<a href="example.pdf">Foo</a> - just like any other link.


This assumes that the web server knows how to correctly identify this file
as a PDF. In some cases it will be necessary to use

<a href="example.pdf" type="application/pdf">Foo</a>

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Mar 24 '06 #5

P: n/a
Tristan Miller <ps********@nothingisreal.com> writes:
Greetings.
In article <e0*******************@news.demon.co.uk>, David Dorward wrote:
landingone wrote:
How do I add a link to download a *.pdf file in Dreamweaver?
<a href="example.pdf">Foo</a> - just like any other link.


This assumes that the web server knows how to correctly identify this file
as a PDF. In some cases it will be necessary to use


No, in some cases it will be necessary to tell the web server (maybe
via its admins if .htaccess isn't supported) that the file is a PDF.
<a href="example.pdf" type="application/pdf">Foo</a>


The type attribute is an advisory attribute for the browser so that it
can suggest *before* the link is clicked on whether the file will be
of a supported format. (In theory - do any browsers do anything useful
with it for anything other than <link rel="stylesheet">)

<a href="example.pdf" type="application/pdf">Foo</a> will not have
example.pdf parsed as PDF when the browser actually retrieves it - the
browser *must* [2] accept whatever content type the server says it is.

There's no harm in adding it (apart from a few extra bytes), but it
won't make up for poor web server configuration.

[1] Assuming a reasonable request. .pdf for application/pdf is
reasonable, .html for image/jpeg is not. ;)
[2] IE wrongly doesn't, but IE would look either at the file and
decide it was a PDF anyway, or treat it as application/octet-stream,
regardless of the link.

--
Chris
Mar 24 '06 #6

P: n/a
On Fri, 24 Mar 2006, Tristan Miller wrote:
<a href="example.pdf">Foo</a> - just like any other link.
This assumes that the web server knows how to correctly identify
this file as a PDF.


How to properly configure a web server is indeed important, but not
really on-topic here.
In some cases it will be necessary to use

<a href="example.pdf" type="application/pdf">Foo</a>


This will almost never be of any use for rendering, since, according
to the specification (RFC2616), a web server SHOULD send an
appropriate content-type, and a web client MUST treat the
server-provided content type as authoritative.

In practice I'd say it's very rare for web servers to fail to follow
the SHOULD requirement. Even IIS usually supplies a content-type[1];
I recently spotted an exception to that rule, but on that occasion the
server was handling an error condition, rather than normal service.
Since the server wasn't mine, I can only report what I saw - I don't
know how the situation really came about.

Most available clients also follow the MUST rule - MSIE is the "odd
one out", in violation of RFC2616. (Opera has, or had, some analogous
fuxup scheme - available as a user option, but enabled by default -
I'm not sure what their current default setting is for it, though).

And even if they don't follow the rules, they often have some other
scheme for guessing what the content type is: any advisory content
type specified in the <a href...> is rather unlikely to be used for
rendering purposes; in theory, a client agent could use it for
deciding that it wasn't worth fetching the resource in question,
because it's of an unsupported type - I don't think browsers make much
use of that, I suppose indexing robots etc. *might* do.

h t h

[1] though it's more likely to be wrong than with other web servers,
since those running IIS are quite likely to be the kind of folk who
rely on MSIE violating the interworking rules.
Mar 24 '06 #7

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
But perhaps most importantly, a link to a PDF file should always be
a) accompanied with a link to equivalent content in a more accessible
format, such as HTML


"Always" is too strong a word, I think. There are cases - downloadable
tax forms, for example - where precise layout is a "hard" requirement.
In such cases, trying to duplicate the content in HTML is not feasible.

The best alternative in such cases is to provide a means (such as an HTML
form) for users to order pre-printed copies for snail-mail delivery, or
to list the places where the forms can be obtained in person.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Mar 24 '06 #8

P: n/a
Sherm Pendley <sh***@dot-app.org> wrote:
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
But perhaps most importantly, a link to a PDF file should always be
a) accompanied with a link to equivalent content in a more accessible
format, such as HTML
"Always" is too strong a word, I think.


I don't think so. Rather, the question is whether the formulation is too
mild.
There are cases - downloadable
tax forms, for example - where precise layout is a "hard" requirement.
It's a hard requirement only if made a hard requirement. If it is, then the
ultimate problem is that requirement, which is discriminatory and
unnecessary, especially in the modern world.
In such cases, trying to duplicate the content in HTML is not feasible.
What is needed is a way to fill out the form in an accessible way and send it
over the network. This won't be easy, of course, especially as regards to
security. But it's the way to go.
The best alternative in such cases is to provide a means (such as an HTML
form) for users to order pre-printed copies for snail-mail delivery, or
to list the places where the forms can be obtained in person.


The main problem is not printing a PDF document (though it can be a problem,
especially if you haven't got a printer) but the need to work with it in the
first place.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Mar 24 '06 #9

P: n/a
Jukka K. Korpela wrote:
(Admittedly, the <a> element is really monstrous jargon. It should
have been something like <link ref="...">...</link>. Who would
_guess_ that "a" means "anchor" and "anchor" means "link"?)


On the same idea:

Why not <list> instead of <ul>. And <list type="ordered"> instead of
<ol>. Other things I wish they had done:

<row>, not <tr>
<cell>, not <td>
<quote>, not <blockquote>, with the idea that user-agents would
automagically indent the quote if it was longer than 4 lines or so

I also rather dislike <head> since it seems to occasionally get confused
with http headers. Perhaps <meta> would have been better? Eh--maybe not
on this one.

--
Brian
remove ".invalid" to email me
Mar 28 '06 #10

P: n/a
Brian wrote:
Jukka K. Korpela wrote:
(Admittedly, the <a> element is really monstrous jargon. It should
have been something like <link ref="...">...</link>. Who would
_guess_ that "a" means "anchor" and "anchor" means "link"?)
On the same idea:

Why not <list> instead of <ul>. And <list type="ordered"> instead of
<ol>. Other things I wish they had done:

<row>, not <tr>
<cell>, not <td>


Then what would <th> be?
<quote>, not <blockquote>, with the idea that user-agents would
automagically indent the quote if it was longer than 4 lines or so


Interesting concept. But <quote> is inline, <blockquote> is block. If
they were merged and the browser could choose on the fly whether to
display it inline or as a block, it would make styling difficult. It
would also mean that it would have to be able to shift between inline
and block as the user changed the browser width or the font size.
Mar 28 '06 #11

P: n/a
Nice X-face. San Tropez, perhaps?

--
Neredbojias
Apprentice Learner
Apr 3 '06 #12

P: n/a
VK

Jukka K. Korpela wrote:
Who would _guess_ that "a" means
"anchor" and "anchor" means "link"?


Anchor doesn't mean link, and <a> is not an anchor until one gives it a
name. Yes, entity name stays from the word <a>nchor because on the CERN
stage of the Web it was presumed that any link will be also made as an
anchor for other links, so all scientific documents could be easily
cross-linked. But it is the commonly accepted practice now to create
links without making them anchors.

<a name="foo"> Anchor
<a href="foobar.html> Link
<a href="foobar.html" name="foo"> Link and Anchor

It is funny that even proficient developers do not remember sometimes
the difference. I encountered the questions like "I have <a href="foo">
so how to jump to it?"

Apr 3 '06 #13

P: n/a
VK wrote:
Anchor doesn't mean link, and <a> is not an anchor until one gives it a
name.


That isn't what the spec says, in fact it goes so far as to say:

href = uri [CT]
This attribute specifies the location of a Web resource, thus defining a
link between the current element (the source anchor) and the destination
anchor defined by this attribute.

Thus explicitly describing the type of anchor created by

<a href="foo"> ... </a>

as a "source anchor".

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Apr 4 '06 #14

P: n/a
VK

David Dorward wrote:
href = uri [CT]
This attribute specifies the location of a Web resource, thus defining a
link between the current element (the source anchor) and the destination
anchor defined by this attribute.

Thus explicitly describing the type of anchor created by

<a href="foo"> ... </a>

as a "source anchor".


So we shouldn't have any problems then to make a link to this anchor
(by using hash part of URI).

<a href="foo">...</a>
....
<a href="#foo">Click to jump to foo</a>

Oops... Doesn't work... What a hey?!
;-)

I don't know where the quoted piece of text came from, but I presume
from W3C. You have to be really careful with their texts though: it is
often that the real meaning is not the one you presume from the first
or even third reading. And it is often that the real meaning is unknown
even to whoever wrote it, like with CSS2 colors shortcuts (a nice way
to say "plain b.s." :-)

As much as can google out, the discussed entity never was presumed to
be an anchor. It is always was reffered as "hypertext link" uncluding
Tim Berners-Lee. At least it is called this way in the oldest text I
could find:

<http://groups.google.com/group/comp.archives/browse_frm/thread/fdc8cfcfde8518e1/ad173ff36141539f?lnk=st&q=%22World+Wide+Web%22&rnu m=13&hl=en#ad173ff36141539f>

Apr 5 '06 #15

P: n/a
VK wrote:
Thus explicitly describing the type of anchor created by
<a href="foo"> ... </a>
as a "source anchor".
So we shouldn't have any problems then to make a link to this anchor
(by using hash part of URI). <a href="foo">...</a>
...
<a href="#foo">Click to jump to foo</a>

Oops... Doesn't work... What a hey?!
Err. So? Anchor doesn't mean "Something you can link to".
I don't know where the quoted piece of text came from, but I presume
from W3C.
http://www.w3.org/TR/html4/struct/links.html#h-12.2
You have to be really careful with their texts though: it is
often that the real meaning is not the one you presume from the first
or even third reading.
It seems distinctly unambitious to me.
And it is often that the real meaning is unknown
even to whoever wrote it, like with CSS2 colors shortcuts (a nice way
to say "plain b.s." :-)
Care to elaborate?
As much as can google out, the discussed entity never was presumed to
be an anchor. It is always was reffered as "hypertext link" uncluding
Tim Berners-Lee. At least it is called this way in the oldest text I
could find:


And obviously the oldest text you can find is more authoritative than the
current recommendation.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Apr 6 '06 #16

P: n/a
VK

landingone wrote:
How do I add a link to download a *.pdf file in Dreamweaver? I admit
I'm not very savvy with this and usually just do a cut and paste from a
*.doc document. I inherited this from someone who set up the website.
Any help would *greatly* be appreciated!!!


<a href="myPDFfile.pdf">PDF file</a>

Please not that with Acrobat Reader installed (highly possible)
clicking on such link will lead to the pdf file being open in the
browser window, not to "Save As" dialog.

And no, you can not enforce from client-side "Save As" dialog for known
file types. This super FAQ was answered a number of times in different
groups like say <http://www.jibbering.com/faq/#FAQ4_33>

On the client-side you can though provide an instruction for your link
like

<a href="myPDFfile.pdf">Please right-click this link and choose Save
option from context menu</a>

Apr 6 '06 #17

P: n/a
In article <11*********************@e56g2000cwe.googlegroups. com>,
VK <sc**********@yahoo.com> wrote:
Please not that with Acrobat Reader installed (highly possible)
clicking on such link will lead to the pdf file being open in the
browser window, not to "Save As" dialog.
Only in IE. Not on other browsers.
And no, you can not enforce from client-side "Save As" dialog for known
file types. This super FAQ was answered a number of times in different
groups like say <http://www.jibbering.com/faq/#FAQ4_33>

On the client-side you can though provide an instruction for your link
like

<a href="myPDFfile.pdf">Please right-click this link and choose Save
option from context menu</a>


(What do one-button Mac users do in this case?)

You can also force special document types (particularly MS Office
types) to open in their own applications rather than inside your
browser. You have to go to My Computer > Folder Options > File
Types > click on the document extension > Advanced > un-check
"Browse in same window."

-A
Apr 6 '06 #18

P: n/a
VK
David Dorward wrote:
Anchor doesn't mean "Something you can link to".
Strong statement :-)

So I guess we have two types of anchors then: the ones you can link to
and the ones you cannot link to. For a further semantical clarification
we need a boatman now :-)

It is OK sometimes to ask the browser itself:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>Link and Anchor</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
<script type="text/javascript">
function demo() {
alert('links: '+document.links.length);
alert('anchors: '+document.anchors.length);
}
window.onload = demo;
</script>
</head>

<body<!-- pretty-print is adjusted for phantom nodes issue
--><ul<li><a href="http://www.google.com">Google</a></li
<li><a href="http://www.yahoo.com">Yahoo!</a></li
<li><a href="http://www.w3.org" name="W3C">W3C</a></li
<li><a name="Locale">Locale</a></li
</ul
</body> </html>

But I guess I know your answer already (from the previous discussion
about NET tag): "the whole world is wrong, only the W3C paper is
right". I really cannot argue with such strong argument.
And it is often that the real meaning is unknown
even to whoever wrote it, like with CSS2 colors shortcuts (a nice way
to say "plain b.s." :-)


Care to elaborate?


Oh sorry, I thought you were one of participants. Look at ciwas about
Safe Color Palette.
And obviously the oldest text you can find is more authoritative than the
current recommendation.


Not always, but if the old text has more sense (and correspondes to the
implemented reality) - then why not? That was a clear term in mid-90's:
"hypertext container to be used as anchor, link or both". IMHO
*semantically*, not talking about technically, it is much better then
"anchor which can be an anchor, be not an anchor, be a link but not an
anchor - but still being an anchor..." It seems I'm already lost - like
that author in W3C :-)

Apr 6 '06 #19

P: n/a
VK wrote:
David Dorward wrote:
Anchor doesn't mean "Something you can link to".
Strong statement :-) So I guess we have two types of anchors then: the ones you can link to
and the ones you cannot link to.
Yes.
It is OK sometimes to ask the browser itself: alert('links: '+document.links.length);
alert('anchors: '+document.anchors.length);
Let us see what the DOM specification has to say about document.links and
document.anchors.

links
A collection of all AREA elements and anchor (A) elements in a document
with a value for the href attribute.

anchors
A collection of all the anchor (A) elements in a document with a value
for the name attribute.Note. For reasons of backwards compatibility, the
returned set of anchors only contains those anchors created with the name
attribute, not those created with the id attribute.

-- http://www.w3.org/TR/1998/REC-DOM-Le...-one-html.html

So the spec says that the anchors property returns only a subset of all the
anchors in the document and that the links property returns (as well as
area elements) anchor elements. (Which qualifies the anchors property as
Yet Another Thing With A Stupid Name).
And obviously the oldest text you can find is more authoritative than
the current recommendation.

Not always, but if the old text has more sense
What would make more sense would be not using <a> elements for links, but we
don't have that.
(and correspondes to the implemented reality) - then why not?


It does correspond to the implemented reality :)

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Apr 6 '06 #20

This discussion thread is closed

Replies have been disabled for this discussion.