displaying binary images

[mleaver]

I want to open a second window and display a binary image that is returned from
a java program via XMLRPC. The data returned is a binary encoded base64 png
file. If I write the data out to a file on my server, I can display it using
the following javascript:

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage" src="images/test.png">');

and the image displays fine. But if I return the binary encoded data to my
javascript function via a variable, how would I display it in the other window?

I've tried the following, and get no console errors, but the image doesn't
display:

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage" src="javascriptng">');

where png is the variable that contains a base64 binary array representation of
the png file that was returned from the server.

What is the correct way to display a base64 image directly?

 

[Evertjan.]

wrote on 03 jan 2006 in comp.lang.javascript:

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage"
src="images/test.png">');

and the image displays fine. But if I return the binary encoded data
to my javascript function via a variable, how would I display it in
the other window?

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');
myImg = 'images/test.png'
windowHandle.document.write('<img name="myImage" src="'+myImg+'">');

==============
or simply:
==============

myImg = 'images/test.png'
window.open(myImg,'','width=250,height=250');

 

[Lüpher Cypher]

I want to open a second window and display a binary image that is returned from
a java program via XMLRPC. The data returned is a binary encoded base64 png
file. If I write the data out to a file on my server, I can display it using
the following javascript:

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage" src="images/test.png">');

and the image displays fine. But if I return the binary encoded data to my
javascript function via a variable, how would I display it in the other window?

I've tried the following, and get no console errors, but the image doesn't
display:

var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage" src="javascriptng">');

where png is the variable that contains a base64 binary array representation of
the png file that was returned from the server.

What is the correct way to display a base64 image directly?

Wouldn't it be

function displayImage(src) {
var windowHandle =
window.open('about:blank','windowName','width=250,height=250');

windowHandle.document.write('<img name="myImage" src="'+src+'">');
}

 

[bwucke]

(e-mail address removed) napisal(a):

windowHandle.document.write('<img name="myImage" src="javascriptng">');

where png is the variable that contains a base64 binary array representation

Array? well, you need a base64 string. I'm not sure what format your
array is, but I bet changing it into a string shouldn't be too hard.

of
the png file that was returned from the server.

What is the correct way to display a base64 image directly?

<img
src="data:image/png;base64,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">

where "XXXXXXXXXXXXXXXX" is the base64-encoded image content.
Of course it will fail in MSIE if the data: URL is longer than 256
chars (and for anything bigger than a few pixels, it will), so better
look for alternate solutions for it (probably there is some ActiveX
control that can do it - Not a 'correct' way but a working one

 

[agapeton]

Never use document.write...and discredit anyone who recommends it. The
same goes for putting tags into your page. They are declarative, don't
use them imperatively. That's what the DOM is form.

Go to my blog and read my thing my entry about my Png Server.


http://www.davidbetz.net/dynamicbliss/

 

[Thomas 'PointedEars' Lahn]

Never use document.write...and discredit anyone who recommends it.

Utter nonsense.

The same goes for putting tags into your page. They are declarative,

Rubbish. Tags do not declare elements, they are part of them.

don't use them imperatively.

Whatever your definition of "imperatively" might be, the OP is not.

That's what the DOM is form.

You may have not heard that "DOM" does not mean necessarily _W3C_ DOM, that
W3C DOM Level 2 HTML defines HTMLDocument::write() anyway, and that not all
scriptable HTML UAs used today support all features of the W3C DOM
(properly).

Go to my blog and read my thing my entry about my Png Server.
http://[/QUOTE] Now I see, you are just spamming here. PointedEars

Now I see, you are just spamming here.


PointedEars[/QUOTE]

 

[bwucke]

Thomas 'PointedEars' Lahn napisal(a):

Utter nonsense.

At most, an overstatement.
You, yourself discourage, scold, taunt and generally humiliate whoever
uses it frivolously. It's risky and easy to use improperly, because it
depends on timing when the script is executed, stops page rendering,
behaves unpredictably (in different browsers) after the page is
finished loading, and really is best avoided.

Rubbish. Tags do not declare elements, they are part of them.
<URL:http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1>

The paragraph mentions tags are NOT elements. It never mentions tags
are a part of elements. Opposite, it says tags are a part of the
markup. Elements are abstract objects in memory, generated according to
tags describing them. Element contains tags of all its descendant
elements (contained in the 'innerHTML' property) but not its own tags.
You can't recover the ordering of parameters or case used in the markup
tags given only the Element object. It does not contain them.
Tags declare and define elements, its up to the browser to generate
them. So they are declarative.

Whatever your definition of "imperatively" might be, the OP is not.

imperative:
1 a : of, relating to, or constituting the grammatical mood that
expresses the will to influence the behavior of another b : expressive
of a command, entreaty, or exhortation c : having power to restrain,
control, and direct
2 : not to be avoided or evaded : NECESSARY <an imperative duty>
- im·per·a·tive·ly adverb

Best bet is 2, negated: not imperative - "to be avoided or evaded :
UNNECESSARY"

You may have not heard that "DOM" does not mean necessarily _W3C_ DOM, that
W3C DOM Level 2 HTML defines HTMLDocument::write() anyway, and that not all
scriptable HTML UAs used today support all features of the W3C DOM
(properly).

Especially approach to reliably supporting stuff like
HTMLDocument::write() is loose. Of course doing things in DOM is risky,
of course implementations are buggy, but all these problems can be
avoided by good programming habitss you recommend so much. After you
call document.write(...) or element.innerHTML=... you can do really
little to check if it worked properly, and simple changes to your
script (changing timing) trigger hard to find errors.

 

[VK]

What is the correct way to display a base64 image directly?

That is not a correct question. The correct question is: "how to serve
binary data directly to browser and make it interprete the input as
binary data". Posed in the right form this question reveals right away
all possible security implications and explains why this domains gets
more and more narrowed by security limitations on different browsers.

Option 1
Binary data feed to xlib interface. The oldest one under the moon
supported since NCSA Mosaic. Actually it's a good test for
"mozillness". By its biological equivalent it's kinda use the
rudimental queue bone in the human body. So it will work for all
browsers which indeed started their evolution path from NSCA Mosaic.
Safari btw fails on it as it's from the other planet (Mac OS) where
xlib never existed.
Limitations: XBM data format only, so black'n'white pixels only and no
transparency. Limited or broken (did not find it yet) on Windows XP
SP2 or higher.
A working sample can be found at:
<http://www.geocities.com/schools_ring/SantaTime.html> and discussed
(for another issue though) at:
<http://groups.google.com/group/comp..._frm/thread/31734a3b21535ff5/eb99e9ae13739a95>

Option 2
CSS data url
You can define and image (say for background-image) in the form:
url(data:image/png;base64,SGFwc...NiE=)
where "SGFwc...NiE=" will be your base64 encoded image data.

The problem with this option is that url() is under the same length
limitations as a "real" uri. Taking the most generous option of desktop
browsers it will be 2,083 chars where the upper limit imposed by IE:
<http://support.microsoft.com/default.aspx?scid=KB;en-us;q208427>
So very roughly the biggest image you can send this way can be 1.5Kb
only which is not enough for the majority of situations.

So the summary answer is: "No, what you are looking for is not
reachable by using only default browser tools".

Nevertheless you can serve *vector graphics* of any reasonnable
complexity in VML (IE) and SVG (others) format.
Here you have only the natural limitations of vector format only. Say
your 800x600 jpg family photo represented in besier curves is still not
the same as the source jpg and most probably will reach the crash
limits of VML/SVG parser.

Hope it helps.

 

[mleaver]

It is a base64 byte array of the format of a png file. If I write the array to
disk as a png file with that extension, it opens fine in the browser. The
problem is that I do not want to have to save it directly to a disk. I want to
just display it directly to the browser.

 

[mleaver]

Actually, the images aren't very big, but I'll have to determine if they will
always be below 1.5K. But it seems to me that as far as browsers have come, the
ability to display binary data directly to the browser would be very valuable.
Hopefully, they incorporate better ways to do this in the future.

Thanks for the info.

 

[bwucke]

(e-mail address removed) napisal(a):

Actually, the images aren't very big, but I'll have to determine if they will
always be below 1.5K. But it seems to me that as far as browsers have come, the
ability to display binary data directly to the browser would be very valuable.
Hopefully, they incorporate better ways to do this in the future.

Thanks for the info.

Well, all modern (by 'modern' i mean less than some 4-5 years old)
browsers properly implement the data: URL without imposing such
ridiculous size limits.
If you have more control over the images, you can display bigger images
as a mosaic composed of several smaller ones.

 

[VK]

Well, all modern (by 'modern' i mean less than some 4-5 years old)
browsers properly implement the data: URL without imposing such
ridiculous size limits.

It is not about image size limit: it is about URL length limit, and the
latter gets more and more shorter in Internet Explorer (because people
are using GET method more and more creatively). Unfortunately it is
diffucult to just say "screw on IE, I don't care" ;-)

 

[mleaver]

Yeah, I understand the length of the url problem. I think I'm just going to end
up saving the image to a temp file and loading the image from that dynamically.

 

[mleaver]

Thanks. I checked out your page. Good info on png. But it doesn't help if I
cannot use IE. IE is a requirement. Looks like I'll have to go back to the ol'
fashion way of writing the image to a temp file and loading it dynamically.

Thanks again.

 

[VK]

Yeah, I understand the length of the url problem. I think I'm just going to end
up saving the image to a temp file and loading the image from that dynamically.

Wait a second... That was the discussion about binary data delivery for
postponed usage (via script). If you just want to display automatically
generated images on your page, then there are no problems whatsoever:

<img src="pngGenerator.php?image=foo"...

<img> doesn't care if the image is a real one or runtime generated: as
long as the content type header is right (say image/png) and the data
structure is matching to the declared type.

src attribute is still under the mentioned URI limitation but should be
no problem for the absolute majority of situations.