Make FFox-Linux automatically view PDFs in Evince ... How?

[Mark Filipak]

Hi All, this is for the Linux crowd.

I'm new to Linux. I tried to open a PDF and expected it to open in
Evince, but it didn't. It would only download. So I checked
'Preferences' > 'Applications' for the file association. For PDF it said
"Document Viewer" (which is supposed to be Evince). Since trying to open
the PDF didn't work, I tried changing the file association explicitly to
"/usr/bin/evince", but it still didn't work. I assumed there must be
some setting somewhere that controlled whether an external command is
evoked or a download is initiated. I hoped to find & change that
setting, but I couldn't find such a setting.

Can anyone give me a clue?

Thank You.
--
Amazing 12-year old insect: Thunderbird Bug 121947.
Does Mozilla bury bugs? See Firefox Bug 1120734.

[Good Guy]

On 21/01/2015 02:30, Mark Filipak wrote:

Hi All, this is for the Linux crowd.

I'm new to Linux. I tried to open a PDF and expected it to open in
Evince, but it didn't. It would only download. So I checked
'Preferences' > 'Applications' for the file association. For PDF it said
"Document Viewer" (which is supposed to be Evince). Since trying to open
the PDF didn't work, I tried changing the file association explicitly to
"/usr/bin/evince", but it still didn't work. I assumed there must be
some setting somewhere that controlled whether an external command is
evoked or a download is initiated. I hoped to find & change that
setting, but I couldn't find such a setting.

Can anyone give me a clue?

Thank You.

Did you try going to:

Tools >> Options >> Applications

And look in the "Content type" and "Action" columns to see if that makes sense.

I don't use Linux so my guess is based on a Windows system

Good luck.

[Caver1]

Edit.Preferences>Applications. scroll down to PDF> click on preview in
Firefox>Click on down triangle>Use Other> point it to Evince which
should be in /bin.

--
Caver1

[Mark Filipak]

On 01/20/2015 09:59 PM, Good Guy wrote:

-snip-
> Tools >> Options >> Applications

in FFox-Linux (and other Linux apps), that's
'Edit' > 'Preferences' > 'Applications' tab.

> And look in the "Content type" and "Action" columns to see if that makes
> sense.

Yes. The default is called "Document Viewer". Linux has a nasty way of
giving applications generic names to hide their real names. In this case
"Document Viewer" == "Evince".
What I did was change the Action from "Document Viewer" to
"/usr/bin/evince" (which is the absolute path to the evince program).
Doing thus is sort of a way to give Linux a dope-slap, but even that
didn't make FFox launch Evince with the PDF in its mouth.

In Windows one can easily make PDFs open in Acrobat or Foxit or
whatever, but I've not done this in Linux. I'm not sure Linux implements
file association at the system level the way Windows does. For example,
in Windows you can make a hierarchical menu of documents (of mixed
types) that operates like a menu but uses file association to open those
documents in the particular application for each particular type of file
(PDF v. TXT v. JPG v. ...). That used to be really easy in WinXP, but
Microsoft (in it's infinite wisdom) made it much harder to make such
menus in Win7.

> I don't use Linux so my guess is based on a Windows system.

Hmmm... I'm told there are differences. Hahahahahahaha.......

Ciao.

[Mark Filipak]

On 01/20/2015 10:32 PM, Caver1 wrote:
> On 01/20/2015 09:59 PM, Good Guy wrote:

> Edit.Preferences>Applications. scroll down to PDF> click on preview in
> Firefox>Click on down triangle>Use Other> point it to Evince which
> should be in /bin.

Actually, it's in '/usr/bin/', but that didn't work. What I get is this
dialog:

You have chosen to open:
Foxes_Eating_Penguins.PDF
which is: PDF document
from: http://www.mozilla.org
What should Firefox do with this file?
(_) DownThemAll!
(o) Save File
[_] Do this automatically for files like this from now on.

I'm not given the choice to view it in Evince.

[»Q«]

In
<news:mailman.8785.142181146...@lists.mozilla.org>,

Mark Filipak <markfilip...@gmail.com> wrote:

> Yes. The default is called "Document Viewer". Linux has a nasty way of
> giving applications generic names to hide their real names.

My guess is that "Evince" is its name and "Document Viewer" is its
description. There's got to be a way to configure your desktop so
that it shows you the names instead of (or at least in addition to)
the descriptions. I'd take it to a list/group for your desktop, which
I take it is GNOME.

> In Windows one can easily make PDFs open in Acrobat or Foxit or
> whatever, but I've not done this in Linux. I'm not sure Linux
> implements file association at the system level the way Windows does.

Since it's Evince and your system is calling it "Document Viewer", I
think we're talking about GNOME. I don't use GNOME, but IIRC actions
for a file type can be edited in the properties dialog for any file of
that type. Properties should be one of the items in the context menu
of the file. I'd also think it can be done in GNOME Control Center,
which is analogous to Windows' Control Panel.

[Mark Filipak]

On 01/21/2015 12:31 AM, »Q« wrote:
> In
> <news:mailman.8785.142181146...@lists.mozilla.org>,
> Mark Filipak <markfilip...@gmail.com> wrote:
>

>> Yes. The default is called "Document Viewer". Linux has a nasty way of
>> giving applications generic names to hide their real names.
>

> My guess is that "Evince" is its name and "Document Viewer" is its
> description. There's got to be a way to configure your desktop so
> that it shows you the names instead of (or at least in addition to)
> the descriptions. I'd take it to a list/group for your desktop, which
> I take it is GNOME.

The desktop shell is XFCE 4. I don't really know much about it, but when
I had install something outside of a distro I was told to choose the
GTK+ version as opposed to the QT version. XFCE is running in Linux Mint
17.1, which I'm told is either a flavor of Ubuntu or Debian. I'm not
sure. Usually, I use Synaptic to add/remove applications if that
provides a clue. The documentation is available only in Hungarian.

I have an application called "Menu Editor" that is actually named
"MenuLibre". I can use that to discover the real names of things. The
launch menu is named "Whiskers Menu" and I'm slowly using MenuLibre to
replace the bogus names with real names. Honestly, I don't know why the
XFCE folks gave things bogus names. Microsoft does the same thing and
calls it "Friendly Name". It's so confusing. As I go through MenuLlibre
configurations I see "GNOME" & "GTK" a lot, and usually together. I'm on
the Linux Mint forum which is where I ask questions, so I don't want to
consume a lot of bandwidth here.

>> In Windows one can easily make PDFs open in Acrobat or Foxit or
>> whatever, but I've not done this in Linux. I'm not sure Linux
>> implements file association at the system level the way Windows does.
>

> Since it's Evince and your system is calling it "Document Viewer", I
> think we're talking about GNOME. I don't use GNOME, but IIRC actions
> for a file type can be edited in the properties dialog for any file of
> that type. Properties should be one of the items in the context menu
> of the file. I'd also think it can be done in GNOME Control Center,
> which is analogous to Windows' Control Panel.

Based on what you wrote, I just installed 'gnome-control-center'. It's
very like what came with XFCE (an applet called simply "Settings" that
doesn't show up in MenuLibre, so I don't know its real name). ...I just
removed 'gnome-control-center' since its redundant. Note: I like how
when you install something, Synaptic gets the dependencies and installs
them too. Too bad that when you uninstall something, Synaptic isn't so
smart.

In any account, I could not solve my problem: How to make FFox
automatically launch Evince with the downloaded PDF in its teeth. Maybe
someone else will respond.

Good try »Q«. Thanks.

--
Amazing 12-year old insect: Thunderbird Bug 121947.

Lizard spits out bug, buries it: Firefox Bug 1120734.

[Mark Filipak]

On 01/21/2015 12:31 AM, »Q« wrote:

-snip-

> Since it's Evince and your system is calling it "Document Viewer", I
> think we're talking about GNOME.

More info...

If I double-click on a PDF, Evince is launched. So the operating system
knows the file association, The problem I'm having is therefore internal
to Firefox, so this is the right forum for me to seek help.

Amusing: When I click on 'Help' > 'About' in Evince, it says its name is
"Document Viewer". The "About Document Viewer" dialog has a link to
'https://wiki.gnome.org/Apps/Evince'. Good grief.

--
Amazing 12-year old insect: Thunderbird Bug 121947.

[anax]

Hi Mark
in FF, Open menu (right hand top line) > Preferences > Applications >
Portable Document Format (PDF). click the right hand column and select
evince

[Caver1]

Your right I forgot /usr.

--
Caver1

[Wolf K.]

I infer that the web page is coded to invoke that dialogue, ie, you
can't change that behaviour. Check the preferred action, and the "Do
this...". That should work.

HTH

--
Best,
Wolf K.
kirkwood40.blogspot.ca

[Wolf K.]

On 2015-01-21 1:57 AM, Mark Filipak wrote:
> On 01/21/2015 12:31 AM, »Q« wrote:
> -snip-
>> Since it's Evince and your system is calling it "Document Viewer", I
>> think we're talking about GNOME.
>
> More info...
>
> If I double-click on a PDF, Evince is launched. So the operating system
> knows the file association, The problem I'm having is therefore internal
> to Firefox, so this is the right forum for me to seek help.

[...]

See the other thread about PDFs not opening.

If this behaviour is limited to certain web-pages, then FF's action is
coded in those pages. If it's universal, then you (and the rest of us)
have been given a stealth security update. Forcing your OS to open the
file should trigger your anti-malware shield for a safety check. Maybe
not as important for *nix, but no OS is invulnerable. But I don't wnat
to start a subthread on that. ;-)

[Wolf K.]

Same behaviour reported in "PDF.js ignored..." thread. Hence my inference.

[Mark Filipak]

I tried to open a PDF link in Firefox and expected it to open in Evince,
but it didn't open at all. Instead I got the usual Firefox download
dialog (below).

I checked Firefox 'Preferences' > 'Applications' for the file

association. For PDF it said "Document Viewer" (which is supposed to be
Evince).

I tried changing the file association explicitly to "/usr/bin/evince",
but it still didn't work.

If I double-click a PDF file in Thunar, it opens in Evince
automatically, so the problem is limited to Firefox, not Linux.

In Firefox I get the usual Firefox download dialog:

> You have chosen to open:
> Foxes_Eating_Penguins.PDF
> which is: PDF document
> from: http://www.mozilla.org
> What should Firefox do with this file?
> (_) DownThemAll!
> (o) Save File
> [_] Do this automatically for files like this from now on.

> ................[_Cancel_] [_Save_File_]
That is coming from Firefox, not the web site.

Note that there is no "Open with ..." option. Thus, it appears that
Firefox is not aware of the PDF file association.

Am I not given the option to open the PDF because there's some other
Firefox setting that I don't know about?

Thank You.

--
Amazing 12-year old insect: Thunderbird Bug 121947.

[WaltS48]

On 01/21/2015 04:57 PM, Mark Filipak wrote:
> I tried to open a PDF link in Firefox and expected it to open in Evince,
> but it didn't open at all. Instead I got the usual Firefox download
> dialog (below).
>
> I checked Firefox 'Preferences' > 'Applications' for the file
> association. For PDF it said "Document Viewer" (which is supposed to be
> Evince).

You do mean 'Preferences' > 'Applications' for the 'Content Type' of
'Portable Document Format (PDF)'?

>
> I tried changing the file association explicitly to "/usr/bin/evince",
> but it still didn't work.

Under 'Action' you chose 'Use other...' and set that to
"/usr/bin/evince" which doesn't work for some reason.

Under 'Action' for my openSUSE with KDE desktop I have these options.

Preview in Firefox
Always Ask
Save File
Use Gimp (Default) meaning default system PDF viewer.
Use other...

What is the default for your choices?

>
> If I double-click a PDF file in Thunar, it opens in Evince
> automatically, so the problem is limited to Firefox, not Linux.

If I set 'Use other...' and navigate to /usr/bin/okular (my Document
Viewer) for KDE. Firefox uses Okular.

>
> In Firefox I get the usual Firefox download dialog:
>> You have chosen to open:
>> Foxes_Eating_Penguins.PDF
>> which is: PDF document
>> from: http://www.mozilla.org
>> What should Firefox do with this file?
>> (_) DownThemAll!
>> (o) Save File
>> [_] Do this automatically for files like this from now on.
>> ................[_Cancel_] [_Save_File_]
> That is coming from Firefox, not the web site.
>
> Note that there is no "Open with ..." option. Thus, it appears that
> Firefox is not aware of the PDF file association.
>
> Am I not given the option to open the PDF because there's some other
> Firefox setting that I don't know about?
>
> Thank You.
>

Is DownThemAll the problem?

--
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

[Mark Filipak]

On 01/21/2015 06:59 PM, WaltS48 wrote:
> On 01/21/2015 04:57 PM, Mark Filipak wrote:

>> I tried to open a PDF link in Firefox and expected it to open in Evince,
>> but it didn't open at all. Instead I got the usual Firefox download
>> dialog (below).
>>
>> I checked Firefox 'Preferences' > 'Applications' for the file
>> association. For PDF it said "Document Viewer" (which is supposed to be
>> Evince).
>

> You do mean 'Preferences' > 'Applications' for the 'Content Type' of
> 'Portable Document Format (PDF)'?

That is correct.

>> I tried changing the file association explicitly to "/usr/bin/evince",
>> but it still didn't work.
>

> Under 'Action' you chose 'Use other...' and set that to
> "/usr/bin/evince" which doesn't work for some reason.

That is correct.

> Under 'Action' for my openSUSE with KDE desktop I have these options.
>
> Preview in Firefox
> Always Ask
> Save File
> Use Gimp (Default) meaning default system PDF viewer.
> Use other...
>
> What is the default for your choices?

The default is "Document Viewer"
The entire drop-down field of choices is:

Preview in Firefox
Always ask
Save file
---------
Use Document Viewer (default)
Use evince
Use other...
---------
Application Details...

>> If I double-click a PDF file in Thunar, it opens in Evince
>> automatically, so the problem is limited to Firefox, not Linux.
>

> If I set 'Use other...' and navigate to /usr/bin/okular (my Document
> Viewer) for KDE. Firefox uses Okular.

That's exactly what I did to specify '/usr/bin/evince'

>> In Firefox I get the usual Firefox download dialog:
>>> You have chosen to open:
>>> Foxes_Eating_Penguins.PDF
>>> which is: PDF document
>>> from: http://www.mozilla.org
>>> What should Firefox do with this file?
>>> (_) DownThemAll!
>>> (o) Save File
>>> [_] Do this automatically for files like this from now on.
>>> ................[_Cancel_] [_Save_File_]
>> That is coming from Firefox, not the web site.
>>
>> Note that there is no "Open with ..." option. Thus, it appears that
>> Firefox is not aware of the PDF file association.
>>
>> Am I not given the option to open the PDF because there's some other
>> Firefox setting that I don't know about?
>>
>> Thank You.
>

> Is DownThemAll the problem?

You are quite right to propose that. I'm embarrassed to say I didn't
think of that (never been a problem before, that is: in Windows), but to
find out I restarted FFox in safe mode.

In Firefox safe mode, I now get this:

> You have chosen to open:
> Foxes_Eating_Penguins.PDF
> which is: PDF document
> from: http://www.mozilla.org

> Would you like to save this file?
> ................[_Cancel_] [_Save_File_]

I quit and then restarted FFox (exited safe mode) and I'm now back to
the original symptom with the original download dialog (top of this
message, and previous messages).

This is quite a mystery. Walt, you are an absolute prince to stick with
me on this. Thank you so very, very much. I don't know what's wrong.
I've looked for another setting in 'Preferences' that might be blocking
an external application (evince in this case) and have found none. If I
wasn't already bald, I'd be pulling my hair out.

--
Amazing 12-year old insect: Thunderbird Bug 121947.

[WaltS48]

Can you provide a link to this page? I tried searching and didn't get
any hits.

[»Q«]

In
<news:mailman.9012.142189373...@lists.mozilla.org>,

Setting it to okular works the same way it does for Walt. I just
installed evince and it works for me the same way. I'm using Gentoo.

I'd take the issue to the Mint folks and see whether they can reproduce
it.

[Mark Filipak]

On 01/21/2015 09:48 PM, WaltS48 wrote:
> On 01/21/2015 09:28 PM, Mark Filipak wrote:

> Can you provide a link to this page? I tried searching and didn't get
> any hits.

I don't know what you searched for. I haven't posted any text from the
page...

...whatever. ...The mystery has been somewhat solved.

If the HTTP request is an explicit '.pdf' request (example:
'http://www.communica.se/multitech/gprs_at.pdf') then everything works
as expected. But if the HTTP request is a GET (in this case:
'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
that merely returns a '.pdf', then FFox doesn't send it to the PDF
reader, but assumes what was returned must be downloaded and saved.

I guess it's just something I'll have to live with.

Thanks all for your help.

[WaltS48]

On 01/22/2015 12:37 AM, Mark Filipak wrote:
> On 01/21/2015 09:48 PM, WaltS48 wrote:

<snipped a bit>

>> Can you provide a link to this page? I tried searching and didn't get
>> any hits.
>
> I don't know what you searched for. I haven't posted any text from the
> page...

I searched for

You have chosen to open:
Foxes_Eating_Penguins.PDF
which is: PDF document
from: http://www.mozilla.org
Would you like to save this file?

.................[_Cancel_] [_Save_File_]

> ...whatever. ...The mystery has been somewhat solved.
>
> If the HTTP request is an explicit '.pdf' request (example:
> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
> as expected. But if the HTTP request is a GET (in this case:
> 'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
> that merely returns a '.pdf', then FFox doesn't send it to the PDF
> reader, but assumes what was returned must be downloaded and saved.
>
> I guess it's just something I'll have to live with.
>
> Thanks all for your help.
>

I have a utility like that. Always have to download and save the PDF.

YW

[Wolf K.]

Aha! It seems that certain websites that trigger the puzzling behaviour.
So I infer (once again) that it's the web-page code that originates the
puzzling behaviour.

So should FF be able to handle that? IMO, yes, I think so. But that's a
nother issue.

HTH

[Mark Filipak]

On 01/22/2015 09:41 AM, Wolf K. wrote:
> On 2015-01-22 8:33 AM, WaltS48 wrote:

>> On 01/22/2015 12:37 AM, Mark Filipak wrote:
>>> On 01/21/2015 09:48 PM, WaltS48 wrote:
>>
>> <snipped a bit>
>>
>>>> Can you provide a link to this page? I tried searching and didn't get
>>>> any hits.
>>>
>>> I don't know what you searched for. I haven't posted any text from the
>>> page...
>>
>> I searched for
>>
>> You have chosen to open:
>> Foxes_Eating_Penguins.PDF
>> which is: PDF document
>> from: http://www.mozilla.org
>> Would you like to save this file?
>> .................[_Cancel_] [_Save_File_]

Hahahahaha... 'Foxes_Eating_Penguins.PDF' was a joke. The actual dialog is:

> You have chosen to open:

> 110012115769-090523857267-.PDF
> which is: PDF document
> from: https://www.firstenergycorp.com

> Would you like to save this file?
> .................[_Cancel_] [_Save_File_]

but '110012115769-090523857267-.PDF' doesn't have very high
entertainment value.

>>> ...whatever. ...The mystery has been somewhat solved.
>>>
>>> If the HTTP request is an explicit '.pdf' request (example:
>>> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
>>> as expected. But if the HTTP request is a GET (in this case:
>>> 'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
>>>
>>> that merely returns a '.pdf', then FFox doesn't send it to the PDF
>>> reader, but assumes what was returned must be downloaded and saved.
>>>
>>> I guess it's just something I'll have to live with.
>>>
>>> Thanks all for your help.
>>
>> I have a utility like that. Always have to download and save the PDF.
>>
>> YW
>

> Aha! It seems that certain websites that trigger the puzzling behaviour.
> So I infer (once again) that it's the web-page code that originates the
> puzzling behaviour.
>
> So should FF be able to handle that? IMO, yes, I think so. But that's a
> nother issue.

It's a dead issue for me now. I'd file a bug report, but I've quit
filing bug reports because it's a waste of time. They never do anything
about them except bury them.

[Dave Royal]

On Thu, 22 Jan 2015 00:37:54 -0500, Mark Filipak wrote:

>
> If the HTTP request is an explicit '.pdf' request (example:
> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
> as expected. But if the HTTP request is a GET (in this case:
> 'https://www.firstenergycorp.com/content/customer/my_account/
View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/
content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
> that merely returns a '.pdf', then FFox doesn't send it to the PDF
> reader, but assumes what was returned must be downloaded and saved.
>
> I guess it's just something I'll have to live with.
>

Mark, if you haven't done so already, look at the thread "PDF.JS ignored
for just one PDF" which Wolf has already referred to. This may be the
same effect - and may not. You'll find an add-on that you might try.

I use OpenSUSE/xfce. You might find, as I did, that Evince/Document
Viewer is not great for some documents. I get bills with black on grey
backgrounds that I need to open in LibreOffice to print, so I always save
by default and choose a viewer by right-click. YMMV.
--
(Remove any numerics from my email address.)

[Mark Filipak]

On 01/22/2015 11:46 AM, Dave Royal wrote:
> On Thu, 22 Jan 2015 00:37:54 -0500, Mark Filipak wrote:

>> If the HTTP request is an explicit '.pdf' request (example:
>> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
>> as expected. But if the HTTP request is a GET (in this case:
>> 'https://www.firstenergycorp.com/content/customer/my_account/
> View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/
> content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
>> that merely returns a '.pdf', then FFox doesn't send it to the PDF
>> reader, but assumes what was returned must be downloaded and saved.
>>
>> I guess it's just something I'll have to live with.
>>

> Mark, if you haven't done so already, look at the thread "PDF.JS ignored
> for just one PDF" which Wolf has already referred to.

Sorry... "PDF.JS"? Is that a web page's javascript?

I don't think a web page can influence what a browser does with a '.pdf'
file, how it displays it, or what choices: viewing versus saving, the
browser presents to the user.

I did a search for "PDF.JS ignored for just one PDF" and found this:
'http://codeverge.com/mozilla.support.firefox/pdf.js-ignored-for-just-one-pdf/2027454'

On that page, Wolf writes "So that behaviour is hard coded into the web
page, and Firefox is simply
doing what it's told to do." Sorry... "doing what it's told to do"? I
don't believe that a web page can tell a browser what to do.

> This may be the
> same effect - and may not. You'll find an add-on that you might try.
>
> I use OpenSUSE/xfce. You might find, as I did, that Evince/Document
> Viewer is not great for some documents. I get bills with black on grey
> backgrounds that I need to open in LibreOffice to print, so I always save
> by default and choose a viewer by right-click. YMMV.

Well, I'm new to Linux and I might find what you found. But if I have to
save, then I'll save to a shared directory and view it in Windows.
That's what I did in my current '.pdf' download (my electric bill).

I tried 'http://winff.googlecode.com/files/winff.1.5.1.en.pdf' and had
no problems. FFox gave me the usual choices:
> (o) Open with [__evince__]
> (_) DownThemAll!
> (_) Save File

I think what's happening is:
If FFox see's a URL ending in '.pdf', then it takes what's returned,
interprets it as PDF, and presents the choices: Open, Save.
Otherwise, FFox only offers: Save, even if what's returned ends in '.pdf'.

[Mark Filipak]

On 01/22/2015 08:33 AM, WaltS48 wrote:

> On 01/22/2015 12:37 AM, Mark Filipak wrote:
>> On 01/21/2015 09:48 PM, WaltS48 wrote:
>

> <snipped a bit>

>
>>> Can you provide a link to this page? I tried searching and didn't get
>>> any hits.
>>
>> I don't know what you searched for. I haven't posted any text from the
>> page...
>

> I searched for

>
> You have chosen to open:
> Foxes_Eating_Penguins.PDF
> which is: PDF document
> from: http://www.mozilla.org
> Would you like to save this file?

> .................[_Cancel_] [_Save_File_]

>
>
>> ...whatever. ...The mystery has been somewhat solved.
>>
>> If the HTTP request is an explicit '.pdf' request (example:
>> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
>> as expected. But if the HTTP request is a GET (in this case:
>> 'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
>>
>> that merely returns a '.pdf', then FFox doesn't send it to the PDF
>> reader, but assumes what was returned must be downloaded and saved.
>>
>> I guess it's just something I'll have to live with.
>>
>> Thanks all for your help.
>>
>
>

> I have a utility like that. Always have to download and save the PDF.

It's Edison Electric. I've downloaded their bills in FFox-Windows for
years without problems -- they open in Foxit PDF reader automatcially --
but in FFox-Linux, no dice. The problem has to be with FFox-Linux.

[Wolf K.]

On 2015-01-22 12:55 PM, Mark Filipak wrote:
[...]

> On that page, Wolf writes "So that behaviour is hard coded into the web
> page, and Firefox is simply
> doing what it's told to do." Sorry... "doing what it's told to do"? I
> don't believe that a web page can tell a browser what to do.

[...]

Well, AIUI, the browser reads the web-page's code, and renders the
web-page as the code indicates. If there's an error in that code, then
the page won't display as the author intended, or maybe not display at
all. HTML is not plain text, it's {text + code}. IOW, HTML is really a
scripting language; its main function is to ensure that a document is
displayed as intended. There are a lot of implications to this, not
least the security aspects.

So in fact every web page "tells the browser what to do."

[Dave Royal]

Mark Filipak <markfilip...@gmail.com> Wrote in message:

> I think what's happening is:
> If FFox see's a URL ending in '.pdf', then it takes what's returned,
> interprets it as PDF, and presents the choices: Open, Save.
> Otherwise, FFox only offers: Save, even if what's returned ends in '.pdf'.

In general extensions like .pdf should have little or no effect in
Linux which normally recognises a file by the mime type in the
http headers. These headers are determined by the web server.
Linux should recognise 'application/pdf' whatever the file name.
The three-letter file extension is a windows (originally DOS)
identifier - though it seems to have spread to Android
too.

A pdf file loaded by a browser does not contain any html. The
browser's action (in Linux anyway) is governed by the mime type
and - we now now - by the 'content-disposition' http header
which can force 'save'.

[WaltS48]

Well see a lot of users still insist on using plugins to view PDF files
when Firefox will open most in a new tab using its built-in PDF viewer
JavaScript file called pdf.js. That is what the "Preview in Firefox"
Action for Content Type "Portable Document Format" does.

Those that are hard coded by the web site like my gas company to force a
download won't, and will give the "What should Firefox do with this
file" dialog.

I think Wolf explained that quite well in another post.

Really? Looking at the source of my gas companies web page the first
link has
"CacheProxyServlet/colorPalette/default/browserVendor/Netscape/browserName/Navigator/browserVersion/unknown/locale/en/forwardurl/nisource/themes/html/wssNisourceGreyTheme/safari_styles.jsp"
in it.

I'm surprised I can use the site at all.

SMDH.

[Mark Filipak]

On 01/22/2015 02:56 PM, Wolf K. wrote:
> On 2015-01-22 12:55 PM, Mark Filipak wrote:
> [...]

>> On that page, Wolf writes "So that behaviour is hard coded into the web
>> page, and Firefox is simply
>> doing what it's told to do." Sorry... "doing what it's told to do"? I
>> don't believe that a web page can tell a browser what to do.

> [...]
>
> Well, AIUI, the browser reads the web-page's code, and renders the
> web-page as the code indicates.

HTML is not code. It is layout. It specifies how the DOM (document
object model) is loaded. That model can then be altered by javascript,
it there is javascript and the javascript writes directly to the DOM.

> If there's an error in that code, then
> the page won't display as the author intended, or maybe not display at
> all. HTML is not plain text, it's {text + code}. IOW, HTML is really a
> scripting language;

No, it's not a scripting language. HTML is not code. It's a bastard
child of SGML (standard generalized markup language). It does not run
scripts. The scripts, if there be any, are javascript.

> its main function is to ensure that a document is
> displayed as intended.

That's not its main function, that's its only function, which can fail
due to bugs in the browser or, more often, poor markup in the HTML.

> There are a lot of implications to this, not
> least the security aspects.

HTML has nothing to do with security.

> So in fact every web page "tells the browser what to do."

No, they do not.

Wolf, I love ya guy, but you don't know what you're writing about.

[Mark Filipak]

On 01/22/2015 04:36 PM, Dave Royal wrote:
> Mark Filipak <markfilip...@gmail.com> Wrote in message:

>> I think what's happening is:
>> If FFox see's a URL ending in '.pdf', then it takes what's returned,
>> interprets it as PDF, and presents the choices: Open, Save.
>> Otherwise, FFox only offers: Save, even if what's returned ends in '.pdf'.
>

> In general extensions like .pdf should have little or no effect in
> Linux which normally recognises a file by the mime type in the
> http headers. These headers are determined by the web server.
> Linux should recognise 'application/pdf' whatever the file name.
> The three-letter file extension is a windows (originally DOS)
> identifier - though it seems to have spread to Android
> too.

Oh, yes of course. You are absolutely correct.

> A pdf file loaded by a browser does not contain any html. The
> browser's action (in Linux anyway) is governed by the mime type
> and - we now now - by the 'content-disposition' http header
> which can force 'save'.

So, Dave. What do you suppose is happening with my electric utility? Is
the only reasonable explanation this: the file that the utility's server
returns doesn't have a MIME-type?

[Mark Filipak]

On 01/22/2015 06:59 PM, WaltS48 wrote:
> On 01/22/2015 01:14 PM, Mark Filipak wrote:

> Well see a lot of users still insist on using plugins to view PDF files
> when Firefox will open most in a new tab using its built-in PDF viewer
> JavaScript file called pdf.js. That is what the "Preview in Firefox"
> Action for Content Type "Portable Document Format" does.

I am not using a plug-in and I am not using a FFox-internal viewer. I'm
using Evince.

> Those that are hard coded by the web site like my gas company to force a

> download won't, and will give the "What should Firefox do with this
> file" dialog.

May I repeat, this worked in Windows. It does not work in Linux.

> I think Wolf explained that quite well in another post.

Wolf wrote nonsense.

> Really? Looking at the source of my gas companies web page the first
> link has
> "CacheProxyServlet/colorPalette/default/browserVendor/Netscape/browserName/Navigator/browserVersion/unknown/locale/en/forwardurl/nisource/themes/html/wssNisourceGreyTheme/safari_styles.jsp"
> in it.
>
> I'm surprised I can use the site at all.

What does a link -- What type of link, eh? -- to a java server process
-- perhaps conditionally executed based on sniffing out Safari, eh? --
have to do with whether you could access the site?

[»Q«]

In
<news:mailman.9017.142190507...@lists.mozilla.org>,

Mark Filipak <markfilip...@gmail.com> wrote:

> ...whatever. ...The mystery has been somewhat solved.
>
> If the HTTP request is an explicit '.pdf' request (example:
> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
> as expected. But if the HTTP request is a GET (in this case:
> 'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
> that merely returns a '.pdf', then FFox doesn't send it to the PDF
> reader, but assumes what was returned must be downloaded and saved.

An explicit 'pdf request' *is* a GET request; entering
<http://www.communica.se/multitech/gprs_at.pdf> in the address bar just
results in Firefox issuing "GET /multitech/gprs_at.pdf HTTP/1.1" to the
server.

What matters, as somebody else mentioned in the thread, is the MIME
headers the server returns. From what you've posted, the energy
company's server is serving a Content-Type header which does identify
the file as a PDF. To figure out any more (unless you just want more
guessing ;) we need to look at the other headers. This extension will
let you see the headers that come with the problematic PDFs:
<https://addons.mozilla.org/firefox/addon/live-http-headers/>.

> I guess it's just something I'll have to live with.
>
> Thanks all for your help.

If you've got time, I really would like to see those headers.

[Wolf K.]

On 2015-01-22 7:50 PM, Mark Filipak wrote:
> On 01/22/2015 02:56 PM, Wolf K. wrote:
>> On 2015-01-22 12:55 PM, Mark Filipak wrote:
>> [...]
>>> On that page, Wolf writes "So that behaviour is hard coded into the web
>>> page, and Firefox is simply
>>> doing what it's told to do." Sorry... "doing what it's told to do"? I
>>> don't believe that a web page can tell a browser what to do.
>> [...]
>>
>> Well, AIUI, the browser reads the web-page's code, and renders the
>> web-page as the code indicates.
>
> HTML is not code. It is layout. It specifies how the DOM (document
> object model) is loaded. That model can then be altered by javascript,
> it there is javascript and the javascript writes directly to the DOM.

Semantics. Code == instructions to some executor.

HTML is a "language", which is just another type of code. It encodes
layout. Word "knows" how to interpret it, Notepad doesn't. Or, if you
like, Word can handle an HTML-generated DOM, and Notepad can't. All
document generating programs have to include code somewhere within the
document file so that it can be displayed (and printed) correctly. If a
program can't interpret the code correctly, the document won't display
or print as it should. Not so many years ago, you could crash a program
by feeding it a file it couldn't handle.

In some contexts it's useful to distinguish between different
types/levels of code. I go back to binary coding days, so I know that
it's code all the way down. ;-)

[...]

>
> Wolf, I love ya guy, but you don't know what you're writing about.

;-)

PS: "Computer language" is a metaphor. A computer language is an
abstract code devised to make it easier for humans to construct
programs. Even the binary codes I first learned were abstractions. They
stood for the holes/no-holes in paper tape. As the tape passed through
the reader, circuits were opened and closed. Before paper tapes, humans
flipped switches and plugged and unplugged cables.

Have a good day,

[Mark Filipak]

On 01/22/2015 10:23 PM, Wolf K. wrote:
> On 2015-01-22 7:50 PM, Mark Filipak wrote:

>> On 01/22/2015 02:56 PM, Wolf K. wrote:
>>> On 2015-01-22 12:55 PM, Mark Filipak wrote:
>>> [...]
>>>> On that page, Wolf writes "So that behaviour is hard coded into the web
>>>> page, and Firefox is simply
>>>> doing what it's told to do." Sorry... "doing what it's told to do"? I
>>>> don't believe that a web page can tell a browser what to do.
>>> [...]
>>>
>>> Well, AIUI, the browser reads the web-page's code, and renders the
>>> web-page as the code indicates.
>>
>> HTML is not code. It is layout. It specifies how the DOM (document
>> object model) is loaded. That model can then be altered by javascript,
>> it there is javascript and the javascript writes directly to the DOM.
>

> Semantics. Code == instructions to some executor.

No, Wolf, it's not semantics. HTML is a structured database. An HTTP
browser uses that database to populate a structure called the "DOM". The
rendering engine (Mozilla's is called "Gecko") then uses the DOM to
render (paint) the page image. During that process, javascript can be
used to modify the DOM, but it's only the javascript that is code, that
is: text strings that are converted to CPU machine instructions. HTML
never generates CPU machine instructions. That is not semantics. That's
a huge difference. For example, HTML will never lock up the computer,
but you can create javascript that will do it. HTML is not
multi-threaded, but javascript can be (with the appropriate and rather
obscure calls to built-in functions).

> HTML is a "language", which is just another type of code.

HTML is never code. It is (sloppily) called a "markup language"
(http://en.wikipedia.org/wiki/Markup_language), but it's not really a
language any more than comma-delimited columnar text (as a spreadsheet
import) is a language.

> It encodes layout. Word "knows" how to interpret it,

HTML is never interpreted. Javascript is interpreted. Visual Basic is
interpreted. Forth is interpreted. PHP is interpreted. Perl is
interpreted. SGML is never interpreted. XML is never interpreted. HTML
is never interpreted. There is no code there.

> Notepad doesn't. Or, if you
> like, Word can handle an HTML-generated DOM, and Notepad can't.

Well, I don't know whether Microsoft Word populates a DOM. I don't know,
but knowing how Microsoft tends to hack software architecture, I doubt
that it does have a DOM. I'll bet it's 100% procedural.

> All
> document generating programs have to include code somewhere within the
> document file so that it can be displayed (and printed) correctly.

HTML has NO CODE anywhere. It includes a script element that can contain
code, but the code syntax and symantics are not in the HTML
specification. They're in the javascript (ecmascript) specification.
HTML is defined in a DTD
(http://en.wikipedia.org/wiki/Document_type_definition) which is purely
static.

> If a
> program can't interpret the code correctly, the document won't display
> or print as it should. Not so many years ago, you could crash a program
> by feeding it a file it couldn't handle.
>
> In some contexts it's useful to distinguish between different
> types/levels of code. I go back to binary coding days, so I know that
> it's code all the way down. ;-)

;-) If you really are a coder, then you know what an interpreter
actually is. Write me a line of HTML that adds 2 numbers.

> [...]

>>
>> Wolf, I love ya guy, but you don't know what you're writing about.
>

> ;-)
>
> PS: "Computer language" is a metaphor.

It's not a metaphor and HTML is NOT a computer language.

> A computer language is an
> abstract code devised to make it easier for humans to construct
> programs. Even the binary codes I first learned were abstractions. They
> stood for the holes/no-holes in paper tape. As the tape passed through
> the reader, circuits were opened and closed. Before paper tapes, humans
> flipped switches and plugged and unplugged cables.

True, but this has nothing to do with HTML.

Why stop there. Why not go all the way back to Ada Lovelace?

> Have a good day,

You also.

[Mark Filipak]

On 01/22/2015 09:38 PM, »Q« wrote:
> In
> <news:mailman.9017.142190507...@lists.mozilla.org>,
> Mark Filipak <markfilip...@gmail.com> wrote:
>

>> ...whatever. ...The mystery has been somewhat solved.
>>
>> If the HTTP request is an explicit '.pdf' request (example:
>> 'http://www.communica.se/multitech/gprs_at.pdf') then everything works
>> as expected. But if the HTTP request is a GET (in this case:
>> 'https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billDetails.html?invoice=090523857267&fromResourceNode=/content/customer/my_account/View_My_Bill/jcr:content/mainpar/billdetails')
>> that merely returns a '.pdf', then FFox doesn't send it to the PDF
>> reader, but assumes what was returned must be downloaded and saved.
>

> An explicit 'pdf request' *is* a GET request; entering
> <http://www.communica.se/multitech/gprs_at.pdf> in the address bar just
> results in Firefox issuing "GET /multitech/gprs_at.pdf HTTP/1.1" to the
> server.
>
> What matters, as somebody else mentioned in the thread, is the MIME
> headers the server returns. From what you've posted, the energy
> company's server is serving a Content-Type header which does identify
> the file as a PDF. To figure out any more (unless you just want more
> guessing ;) we need to look at the other headers. This extension will
> let you see the headers that come with the problematic PDFs:
> <https://addons.mozilla.org/firefox/addon/live-http-headers/>.

Excellent, »Q«. I could have used that in the past in lieu of Wireshark.
Thank you very much.

>> I guess it's just something I'll have to live with.
>>
>> Thanks all for your help.
>

> If you've got time, I really would like to see those headers.

Absolutely. Here ya go (and do let me know what you find):

----------------------------------------------------------
https://www.firstenergycorp.com/content/customer/my_account/View_My_Bill.billView.html?invoice=090523857267

GET
/content/customer/my_account/View_My_Bill.billView.html?invoice=090523857267
HTTP/1.1
Host: www.firstenergycorp.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://www.firstenergycorp.com/my_account/View_My_Bill.html
Cookie: JSESSIONID=aad45291-d0d3-461d-87ad-4f48eb7b82da;
BIGipServerfecorp-ssl-pool=562064532.47873.0000; loggedin=true
Connection: keep-alive

HTTP/1.1 200 OK
Date: Fri, 23 Jan 2015 06:04:07 GMT
Server: IBM_HTTP_Server
Content-Disposition: attachment; filename="110012115769-090523857267-.PDF"
Content-Type: application/octet-stream
Set-Cookie: JSESSIONID=aad45291-d0d3-461d-87ad-4f48eb7b82da; Path=/;
HttpOnly
via: 1.1 www.firstenergycorp.com
Vary: Accept-Encoding
Content-Encoding: gzip
P3P: CP="NOI"
Keep-Alive: timeout=30, max=495
Connection: Keep-Alive
Transfer-Encoding: chunked
----------------------------------------------------------

"application/octet-stream"? The question now is: Why does FFox-Windows
work differently?

Windows choices: "Open in Foxit" or "DownThemAll!" or "Save File".
Linux choices: "DownThemAll!" or "Save File".

[Mark Filipak]

Contrast what I posted last with the following:

----------------------------------------------------------
http://www.communica.se/multitech/gprs_at.pdf

GET /multitech/gprs_at.pdf HTTP/1.1
Host: www.communica.se

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1

Connection: keep-alive

HTTP/1.1 200 OK

Content-Type: application/pdf
Last-Modified: Fri, 07 Jan 2005 14:02:24 GMT
Accept-Ranges: bytes
Etag: "0582f83c1f4c41:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Fri, 23 Jan 2015 06:17:43 GMT
Content-Length: 1071806
----------------------------------------------------------

gprs_at.pdf opens in Evince automatically (no dialog at all).
Note: "application/pdf".

[Dave Royal]

Mark Filipak <markfilip...@gmail.com> Wrote in message:

> So, Dave. What do you suppose is happening with my electric utility? Is
> the only reasonable explanation this: the file that the utility's server
> returns doesn't have a MIME-type?
>

To find out you need to discover the http headers that come with
that file (not the headers of the webpage that contains it).

wget -S http:/............filename.pdf
is one easy way to display them in Linux.

That's how I discovered the content-displosition header in the
other thread. (I /expected/ the mime type to be wrong.)

[Dave Pyles]

"application/octet-stream" is not a valid mime type for a PDF file.
"application/octet-stream" is used to describe arbitrary binary data,
typically an ".exe" file, which would most often be downloaded.

Dave Pyles

[Dave Royal]

Dave Pyles <dnp...@user.invalid> Wrote in message:

>
> "application/octet-stream" is not a valid mime type for a PDF file.
> "application/octet-stream" is used to describe arbitrary binary data,
> typically an ".exe" file, which would most often be downloaded.
>

Plus there is content-disposition: attachment just like in the
other thread. Either would cause Fx to download it
IMO.
(I'm mildly surprised it opens by default in a pdf viewer by in
Linux once it's downloaded.)

[Wolf K.]

On 2015-01-23 12:46 AM, Mark Filipak wrote:
> No, Wolf, it's not semantics. HTML is a structured database. An HTTP
> browser uses that database to populate a structure called the "DOM". The
> rendering engine (Mozilla's is called "Gecko") then uses the DOM to
> render (paint) the page image. During that process, javascript can be
> used to modify the DOM, but it's only the javascript that is code, that
> is: text strings that are converted to CPU machine instructions. HTML
> never generates CPU machine instructions. That is not semantics. That's
> a huge difference. For example, HTML will never lock up the computer,
> but you can create javascript that will do it. HTML is not
> multi-threaded, but javascript can be (with the appropriate and rather

> obscure calls to built-in functions). [...]

OK, so "code" is anything that is converted into machine instructions. I
can live with that. ;-)

But "convert into machine instructions" is a multi-layered process. As
you say, "The rendering engine (...) then uses the DOM to render the
page image." Yes, and any given datum ultimately invokes some specific
machine language instructions. From my POV, a datum is a merely one step
more abstract than program code. IOW, datum --> program code --> [...]
--> machine language, where [...] stands for whatever translation
processes are invoked.

I can live with that too.

This a.m., I woke realising that an ASCII stream may be considered a
type of code. Given that the program assumes the data is ASCII, each
byte is an instruction to display (etc) a specific character.

This subthread is becoming philosophical. But thanks for making me once
more think through what I understand as "programming", etc. BTW, I now
understand the claim that "everything is data" a little better. I think.
Maybe. ;-)

[Wolf K.]

On 2015-01-23 10:02 AM, Wolf K. wrote:
> On 2015-01-23 12:46 AM, Mark Filipak wrote:

>> No, Wolf, it's not semantics. HTML is a structured database. [etc]

I think this subthread should go to another forum if you wish to
continue. I'm good, I understand and agree with your technical points.

[Mark Filipak]

On 01/23/2015 10:02 AM, Wolf K. wrote:
> On 2015-01-23 12:46 AM, Mark Filipak wrote:

>> No, Wolf, it's not semantics. HTML is a structured database. An HTTP
>> browser uses that database to populate a structure called the "DOM". The
>> rendering engine (Mozilla's is called "Gecko") then uses the DOM to
>> render (paint) the page image. During that process, javascript can be
>> used to modify the DOM, but it's only the javascript that is code, that
>> is: text strings that are converted to CPU machine instructions. HTML
>> never generates CPU machine instructions. That is not semantics. That's
>> a huge difference. For example, HTML will never lock up the computer,
>> but you can create javascript that will do it. HTML is not
>> multi-threaded, but javascript can be (with the appropriate and rather

>> obscure calls to built-in functions). [...]
>
> OK, so "code" is anything that is converted into machine instructions. I
> can live with that. ;-)
>
> But "convert into machine instructions" is a multi-layered process. As
> you say, "The rendering engine (...) then uses the DOM to render the
> page image." Yes, and any given datum ultimately invokes some specific
> machine language instructions.

You're inappropriately blurring the line between code and data, my
friend. It's really a bright line. Code will make decisions based on
data of course, but that doesn't mean that data is code. Code alters
(processes) data. The code is unchanged in the process. Data is what is
changed. Data is stuff that's worked on, like coke and iron to steel.
It's an input. The page is the steel. In this case, HTML is the recipe
for steel, but it's not the thing (code) that actually makes the steel.

Consider this: code is to travel as page markup (HTML) is to a map. Page
markup is no more code than a map is travel.

> From my POV, a datum is a merely one step
> more abstract than program code. IOW, datum --> program code --> [...]
> --> machine language, where [...] stands for whatever translation
> processes are invoked.

That "-->" between "datum" (why are you using the singular for "data"?)
and "program code" doesn't exist as a work flow. The program code exists
entirely independently from the data and is unaltered by the data. In
fact, it is the data that's altered. Your last step, "machine language",
is more properly "machine instructions" because at that point it is non
human-readable numbers (i.e., ones and zeros) that perform electrical
operations on registers (banks of electronic, "on"/"off" switches)
inside the CPU. It is inside those registers where the data is
manipulated. It's machine instructions that load the registers with
memory data (memory read), manipulate the contents, and store the
contents back to memory (memory write). Code is those machine
instructions (a compiled program), or human-readable text (scripts) that
an intermediate process called an "interpreter" translates into machine
instructions. The javascript interpreter built into Firefox is an
example of such an interpreter. The Basic programming language is
another. Perl is an interpreter that's built into many flavors of Linux
and Unix. PHP is an interpreter in many servers.

So the work flow is:
1, Compiled code flow: Machine instructions convert HTML data into
pictures by manipulating the data within CPU registers, or
2, Interpreter code flow: Machine instructions convert a text (script)
into machine instructions by manipulating the text within CPU registers,
which then convert HTML data into pictures by manipulating the data
within CPU registers.

Think of a compiled program as a script that's been "hardened". Scripts
are human readable, so they're easier to alter and adapt to various
purposes, but the 2-step interpreter process is much slower than what a
compiled program can do.

The reason why HTML is more like a map than a script is that it is
static like a map whereas a script is dynamic -- stuff happens! --
unless of course you're looking at a map of Hawaii or Iceland. :-)

> I can live with that too.
>
> This a.m., I woke realising that an ASCII stream may be considered a
> type of code. Given that the program assumes the data is ASCII, each
> byte is an instruction to display (etc) a specific character.

The ASCII code is merely an index into a dataset. "A" is 1000001, "B" is
1000010, "Z" is 1011010, "a" is 1100001. etc. An ASCII stream is, 1,
data strings of indexes, and 2, obsolete: ANSI is the 8-bit version of
ASCII and succeeded ASCII a few decades ago.

> This subthread is becoming philosophical. But thanks for making me once
> more think through what I understand as "programming", etc. BTW, I now
> understand the claim that "everything is data" a little better. I think.
> Maybe. ;-)
>
> Have a good day,

Take good care. I hope I didn't bore too much.

[Mark Filipak]

On 01/23/2015 07:24 AM, Dave Pyles wrote:
> On 1/23/2015 1:13 AM, Mark Filipak wrote:

> "application/octet-stream" is not a valid mime type for a PDF file.
> "application/octet-stream" is used to describe arbitrary binary data,
> typically an ".exe" file, which would most often be downloaded.

Indeed, yet Firefox for Windows discovers it's actually a PDF and opens
it in a PDF reader, whereas Firefox for Linux does not.

[»Q«]

In
<news:mailman.9048.142202004...@lists.mozilla.org>,

Dave Royal <da...@dave123royal.com> wrote:

> Dave Pyles <dnp...@user.invalid> Wrote in message:
>
> > "application/octet-stream" is not a valid mime type for a PDF file.
> > "application/octet-stream" is used to describe arbitrary binary
> > data, typically an ".exe" file, which would most often be
> > downloaded.
>
> Plus there is content-disposition: attachment just like in the
> other thread. Either would cause Fx to download it IMO.

For the content-disposition issue, there's
<https://addons.mozilla.org/firefox/addon/inlinedisposition/>. (I
think this was posted to the other thread.)

> (I'm mildly surprised it opens by default in a pdf viewer by in
> Linux once it's downloaded.)

Once the file is on local storage, the system can look inside it to see
what kind of file it is. The filename, including any extension, is
ignored.

[»Q«]

In
<news:mailman.9127.142199358...@lists.mozilla.org>,

Any Firefox is supposed only to offer save options for
application/octet-stream files, no open options. Without extensions, I
don't think there's any way to get it to do otherwise. So my guess is
that either the server is sending different headers based on
OS-sniffing or there's an extension on your Windows machine giving you
the "open with" options. (I'm not familiar with DownThemAll!, but it
seems like a likely candidate. I don't know whether DTM! even has
settings that could be different on the different machines.)

[J. P. Gilliver (John)]

In message
<mailman.9085.142204549...@lists.mozilla.org>, Mark
Filipak <markfilip...@gmail.com> writes:
[]

>You're inappropriately blurring the line between code and data, my
>friend. It's really a bright line. Code will make decisions based on
>data of course, but that doesn't mean that data is code. Code alters
>(processes) data. The code is unchanged in the process. Data is what is
>changed. Data is stuff that's worked on, like coke and iron to steel.
>It's an input. The page is the steel. In this case, HTML is the recipe
>for steel, but it's not the thing (code) that actually makes the steel.
>
>Consider this: code is to travel as page markup (HTML) is to a map. Page
>markup is no more code than a map is travel.

[]
You've obviously not encountered self-modifying code ... (-:

(Take to mozilla.general if replying ...)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Fortunately radio is a forgiving medium. It hides a multitude of chins ...
Vanessa feltz, RT 2014-3/28-4/4