Well here´s the thing, I am using the Terminal to do this. With a text editor such as nano I create a plain text file with the content: "GIF89a2017" and I save it as rare.gif
Here´s the thing, when I do file rare.gif it gives me this output: rare.gif: GIF image data, version 89a, 12338 x 14129 and that is indicating that it is a GIF image with a resolution of 12338 x 14129 and that's what I don't understand. Where´s that resolution coming from?
Another thing is, I thought extension didn't really decide what type of file it is, for example when I take a .gif and convert it into and .exe it still recognises it as a GIF image with the file command. I'm gonna guess that in the problem that I have it is recognised as a GIF image because it was created with the GIF extension but I'd like to know why.
Thanks to everyone!
Where´s that resolution coming from?
It's coming from the (bogus) GIF89 header you put in the file. The four bytes following "GIF89a" define the width and height. Each one is stored as a 16-bit unsigned integer. The characters you put there -- 2017 -- are interpreted as:
32 30 ("20") -- 0x3032 = 12338
31 37 ("17") -- 0x3731 = 14129
I'm gonna guess that in the problem that I have it is recognised as a GIF image because it was created with the GIF extension but I'd like to know why.
No, file doesn't look at extensions. It's because the file had a semi-valid GIF header. If you changed the header to something that didn't start with "GIF89a", it will no longer be recognized as a GIF.
Related
I'm attempting to customize the webUI of a Tasmota binary for an espressif based device. My goal is to embed a base64 encoded PNG into the main page so that the image is available even if the internet connection is unavailable.
I have converted a sample image to base64 via CLI as well as several online converters, and have validated the base64. if I plug the data URI into my browser, the image renders correctly, but if I compile the binary and flash the device to view the page, I receive an error and a broken thumbnail.
my current image is
iVBORw0KGgoAAAANSUhEUgAAAEgAAAAPCAMAAABwbnmhAAADAFBMVEUAAAD////+/v79/f38/Pz7+/v6+vr5+fn4+Pj39/f29vb19fX09PTz8/Py8vLx8fHw8PDv7+/u7u7t7e3s7Ozr6+vq6urp6eno6Ojn5+fm5ubl5eXk5OTj4+Pi4uLh4eHg4ODf39/e3t7c3Nzb29va2trY2NjX19fW1tbV1dXU1NTT09PS0tLR0dHQ0NDPz8/Ozs7Nzc3MzMzLy8vKysrJycnIyMjHx8fGxsbFxcXExMTDw8PCwsLBwcHAwMC9vb27u7u3t7e1tbWysrKxsbGwsLCtra2rq6upqamoqKimpqalpaWkpKSjo6OioqKhoaGgoKCenp6ampqZmZmYmJiXl5eVlZWTk5OSkpKRkZGQkJCPj4+Ojo6NjY2MjIyLi4uJiYmIiIiHh4eGhoaFhYWEhISBgYGAgIB/f39+fn59fX18fHx6enp5eXl3d3d1dXVycnJwcHBvb29ra2tqamppaWloaGhnZ2dmZmZlZWVkZGRiYmJhYWFfX19eXl5dXV1cXFxbW1taWlpZWVlYWFhXV1dWVlZVVVVUVFRTU1NSUlJRUVFQUFBPT09NTU1MTExLS0tKSkpISEhHR0dGRkZFRUVDQ0NBQUFAQEA/Pz8+Pj49PT08PDw7Ozs6Ojo5OTk4ODg3Nzc2NjY0NDQyMjIxMTEvLy8uLi4tLS0rKysqKiopKSkoKCgnJycmJiYlJSUkJCQjIyMiIiIhISEgICAfHx8dHR0cHBwbGxsZGRkYGBgWFhYVFRUUFBQTExMSEhIREREQEBAPDw8ODg4NDQ0MDAwLCwsKCgoJCQkICAgHBwcGBgYFBQUEBAQDAwMCAgIBAQH///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfIeyiAAABAHRSTlP//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////wD/////////////////////////////////////////////////////////////c2WY+gAAAAlwSFlzAAALEwAACxMBAJqcGAAABxhpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDYuMC1jMDAyIDc5LjE2NDQ2MCwgMjAyMC8wNS8xMi0xNjowNDoxNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VFdmVudCMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIDIxLjIgKE1hY2ludG9zaCkiIHhtcDpDcmVhdGVEYXRlPSIyMDIxLTAxLTIxVDE3OjQxOjAxLTA4OjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAyMS0wMS0yOFQxODo1NTozNi0wODowMCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAyMS0wMS0yOFQxODo1NTozNi0wODowMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjIiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo2ZjJlM2NiYi05NjI1LTQwNjMtOTlmMi05MDZkNDc3ZTgzNmUiIHhtcE1NOkRvY3VtZW50SUQ9ImFkb2JlOmRvY2lkOnBob3Rvc2hvcDpmYTE1NDdjZi03MzhmLWYwNDMtOWNjNC1mMGNhMTM1ZWI3YTEiIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo3OWRlMGZkYy0zZDAyLTQ4NzYtYWVmZC03Zjg0ZWUxN2QyNDciPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjc5ZGUwZmRjLTNkMDItNDg3Ni1hZWZkLTdmODRlZTE3ZDI0NyIgc3RFdnQ6d2hlbj0iMjAyMS0wMS0yMVQxNzo0MTowMS0wODowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIDIxLjIgKE1hY2ludG9zaCkiLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1ldGVycz0iZnJvbSBpbWFnZS9naWYgdG8gaW1hZ2UvcG5nIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDo3ODExOTllZS1kNzdjLTRmM2ItODRmZi05ZmRlMGJlY2I5M2QiIHN0RXZ0OndoZW49IjIwMjEtMDEtMjhUMTc6MjM6NDQtMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCAyMS4yIChNYWNpbnRvc2gpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDo2ZjJlM2NiYi05NjI1LTQwNjMtOTlmMi05MDZkNDc3ZTgzNmUiIHN0RXZ0OndoZW49IjIwMjEtMDEtMjhUMTg6NTU6MzYtMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCAyMS4yIChNYWNpbnRvc2gpIiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PrCJQdUAAADOSURBVDgRY2CkEmAYjAYxMDBoI/gMDBuROQwMoXAWXNwGmQOSycQwCKxhBQGDrFB4UDbEICFknQwMC/AaZAFVBeWmwA1C8ifDQoiaqSjmMqDoNGWYj2oSsotgIoyMWyBqOnEaZMwwDS6Bw6ADDOwIzcy4vAamdFHdhIg1DyBrPwMLsjNwGATV7IiqCm7QBUbGvQxMqCGO1SC4I0LhqrRhBrmB+XuQQgKVgWwQkqICGAtukAOQcQSh5ChQ8ChUDZjkQRiEEu6+COvODsq8BgBH7haTEIBidQAAAABJRU5ErkJggg==
and my insertion is
"<img src='data:image/png;charset=utf-8;base64,**base64string**'>"
which I have tried both with and without specifying charset, I've tried inserting my code within or around div and p tags...
this webserver is contained within a .ino which I am compiling with platformio, hence the outer " " and the inner ' '
safari is reporting: Failed to load resource: Data URL decoding failed
when I view the source, I see
<img src='data:image/png;charset=utf-8;base64,iVBORw0KGgoAAAANSUhEUgAAAR8AAAA6CAMAAAC+n61OAAADAFBMVEUAAAD////+/v79/f38/Pz7+/v6+vr5+fn4+Pj39/f29vb19fX09PTz8/Py8vLx8fHw8PDv7+/u7u7t7e3s7Ozr6+vq6urp6eno6Ojn5+fm5ubl5eXk5OTj4+Pi4uLh4eHg4ODf39/e3t7c3Nzb29va2trY2NjX19fW1tbV1dXU1NTT09PS0tLR0dHQ0NDPz8/Ozs7Nzc3MzMzLy8vKysrJycnIyMjHx8fGxsbFxcXExMTDw8PCwsLBwcHAwMC9vb27u7u3t7e1tbWysrKxsbGwsLCtra2rq6upqamoqKimpqalpaWkpKSjo6OioqKhoaGgoKCenp6ampqZmZmYmJiXl5eVlZWTk5OSkpKRkZGQkJCPj4+Ojo6NjY2MjIyLi4uJiYmIiIiHh4eGhoaFhYWEhISBgYGAgIB/f39+fn59fX18fHx6enp5eXl3d3d1dXVycnJwcHBvb29ra2tqamppaWloaGhnZ2dmZmZlZWVkZGRiYmJhYWFfX19eXl5dXV1cXFxbW1taWlpZWVlYWFhXV1dWVlZVVVVUVFRTU1NSUlJRUVFQUFBPT09NTU1MTExLS0tKSkpISEhHR0dGRkZFRUVDQ0NBQUFAQEA/Pz8+Pj49PT08PDw7Ozs6Ojo5OTk4ODg3Nzc2NjY0NDQyMjIxMTEvLy8uLi4tLS0rKysqKiopKSkoKCgnJycmJiYlJSUkJCQjIyMiIiIhISEgICAfHx8dHR0cHBwbGxsZGR</div><div id=' l1' name='l1'>
it's clearly not pulling all of the base64 or truncating it. I'm counting 799 characters in the browser debug of the base64 string, despite the full length of the string is 5168 characters. additionally, safari is complaining about eb('l1').innerHTML = s; citing "null is not an object" and I've no idea what that means or where's coming from.
I'll be the first to admit that I have a tenuous grasp of HTML, even less of CSS, and even less of web language contained within a .ino
happy to receive any pointing in any direction, if this is too big of a can of worms to digest.
oh, also I suppose it's possible to enable SPIFFS and just host the .png on the device's filesystem, but I'm probably even further away from understanding how to implement that. if that's easier, I'm more than willing to go down that road.
Flash size is 1M and binary is currently 602K, so there is some room left.
source code available at https://github.com/arendst/Tasmota/releases/
Tasmota v9.2.0
EDIT:
I have created a 5px x 5px (and consequently 1px x 1px) test image, and same issue. if I load the page and debug, I see the error. If I edit the source html and paste the correct code and close the ", the image then loads.
the browser shows:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAIAAAACDbGyAAAK3GlDQ1BEaXNwbGF5AABIiZWXB1BTWReAz3uphIQWCEVK6E2QXqWEHkBBOohKSAIJJYQUVOzK4gquBRURLCu6IqLg6grIWhALtkWw9wVZVNR1sWBDZR/wE/x35p9/9sycd7935txT3tw7cx4ALZUjFuegagC5IpkkJjSAmZScwiT1AQLaoAY4sOBwpWJWdHQkYDK+fiMIwLubI0+Aa3YjseDfiQaPL+ViYVIxTudJubkYt2L6lSuWyABwGIPpXJl4hP/AWFOCFYjxhxHOHGU8dYTTx5g56hMXE4ixCwCZyuFIMgGo/pidWcDNxOJQ0zB2EPGEIozXYezLFXB4GHdiPDk3N2+EP2NshfmLAWhmGHukfxMz87/ipyvicziZCh7ra1TIQUKpOIcz/19+mv8vuTny8RwWmFIFkrCYMUZuZ+dFKFiUPj1qnIW8cX/ktkAeFj/OXGlgyjjzOEERir050yPHOUMYwlbEkbHjxpkvDY4dZ0lejCJXhiSQNc4cyUReeXa8wi7gsxXxCwVxieNcIEyYPs7S7NiICZ9AhV0ij1HUzxeFBkzkDVH0niv9pl8hW7FXJogLU/TOmaifL2JNxJQmKWrj8YOCJ3ziFf5iWYAilzgnWuHPzwlV2KUFsYq9MuxwTuyNVnzDLE549DhDHAhADiLgAR8kkA55kAMyYEIQCEEKYuyNA9hxkvHnyUaaC8wTz5cIMwUyJgu7gXwmW8S1n8x0cnByBBi5z2NH5A1j9J4ijIsTtvxWAM8</div><div id=" l1'="" name="l1">
I can see that the base64 is truncated, and the SRC URL is no longer closed by a second set of ". if I manually insert the closing " paste the remainder of the code into the source, the image then renders.
it looks like something in the string (or perhaps a length restriction in the webserver.ino is breaking this?
I want to extract these telephone numbers from the website, either as an image or if possible as a string.
Here is an example from the website: Link
As you can see the telephone number is an image.
However I cant seem to view the image when I open the image source:
<img src="http://www.callmyname.sg/search/display_phone_number/VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0=">
But when put into html and viewed in a browser, you can see the image fine.
It's a solution to prevent people like you from scraping their website :)
The url http://www.callmyname.sg/search/display_phone_number/VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0= leads to a script that generates the image - probably based on the argument.
VUhkVE1WOW5BV1lFWWxSbVhUdFRObGMzQlRBRU9nPT0=
Since it ends with an equals sign, I tried to decode it as base64:
UHdTMV9nAWYEYlRmXTtTNlc3BTAEOg==
Now it looks even more like base64, so I tried another round:
PwS1_gfbTf];S6W70:
So it's clearly not plaintext (or not encoded with base64), which would be ridiculous and would let you extract the number this way. They either use some special cipher, or store the numbers in database with this as identifier.
I don't think you can steal the phone number easily, only using OCR perhaps.
When you visit the URL, you will get garbage, since they do not send proper MIME header
�PNG IHDR�,���tRNS���7X}4IDATx���_HZo�g�� E��p��l��EHTx!]�DtQ�M�.x3��.dx�*b]Dl"]�D���bQq.B����Z2$��:ȡ�wq��9�s���Cx>W�}���ٳ��ڶ����]���Ǐ�/_���ݿ���ahh���\q����������555�=���*�"�*�*�f�����}uu�e�d2���o����?00p����J%ȴds���BB�˲�`�`0RJy����n�{cc�e�H$b�ۻ����(�~�_����A4�Z��_�V|��J�w�����t:��333.��ƕ������+^����L`���֑��W��3�X�" y���$p'U"��F���y���z&�ioo��萟�*� ����\�L&Sx����p�e���ׯ_R��y�J%�~����|qq��|e�Z%:�J�{��q��nW�ՉD"�J��~�n4��������̔Ty���qF���>BwGa�z����������8��ߡc�f��B�>!�Ub�N�s���|�F�^/B���Lj��i��NfJ��͛D"����� o!t��`����fvv�eم��V���D)�����x���d2966&�n� ^,0O4��(!D��l�h46�-�~��Tً>B�"�Q�>,�P��ok#U \�BU,�P���=G SA+GIEND�B`�
but it's really just ordinary PNG image:
img http://www.callmyname.sg/search/display_phone_number/VUhkVU5scGlBV1lDWWdFelVEUUhZQWRvQlRZR013PT0=
It's a PNG image, but the server doesn't specify the right content header. It tells your browser that is't an html page in UTF-8 encoding, so you just see some garbage (including the letters PNG at the start).
The <img> tag though doesn't know how to display text so it just tries to load it as an image (and with success).
I don't see a way to extract the numbers in any other way than just reading the image. Because it contains only numbers and will have a similar format all the time, maybe you can find a simple way to parse it instead of using a full fledged OCR library.
It's actually a png-file, generated by a computer before being displayed. You can reference it fine from any other page though, and you should also be able to download it easily (right click, save as ...) Note: I tested this, make sure you save the image with the extension .png and not .html which it will default to.
<img src="http://www.callmyname.sg/search/display_phone_number/QkNOVE1RODNBV1lDWWdVM1V6ZFZNZ1JyRFQ0Rk1BPT0=">
Is there any way to convert a TTF to PNG files? Or any other method to create Sprite out of TTF file in LIBGDX framework? Is there any application available for it?
Before running
LibGDX has a built-in tool in the gdx-toolsproject called Hiero. Just run that project as a java application, and when asked which class to run, choose that one. It lets you take a .ttf file and render it the characters you need (in a size given in pixels), plus it generates a file that contains information about where each character is on the texture. In the program, it's very simple to initialize and use:
BitmapFont font = new BitmapFont(Gdx.files.internal("data/font/font.fnt"));
...
font.draw(spriteBatch, "Text to output", coordX, coordY);
(font.fnt is the file containing the texture positions and other relevant information, it also refers to the .png which is created in the same folder by default.)
You can take a look at the BitmapFont documentation here.
During runtime
A disadvantage of Hiero is that bitmap fonts don't really scale well, so they can look quite bad on different screen resolutions.
Take a look at this answer to a related question:
One solution is to use the FreeType extension to libgdx, as described here. This allows you to generate a bitmap font on the fly from a .ttf font. Typically you would do this at startup time once you know the target resolution.
I haven't personally used it, but it seems like something worth checking out. It looks very simple as well - the example code in the linked answer is 5 lines long.
Finally I got the solution to the same problem(TTF to PNG) which I faced too.
Follow the below steps,
1. Convert TTF to SVG
Use TTF to SVG conversion tool to convert your custom or downloaded TTF file to SVG file
2. Convert SVG to PNG/PDF/TTF:
Goto IcoMoon, in the top left corner, there will be button to Import Icons, click and upload your converted SVG file.
In the bottom bar, there will be an option "Generate SVG & More" as in the below image, click on it
Next, Click the Settings gear icon near "Download" option to override size, output formats(PDF,PNG,etc.,) and then close the Settings
Now click download to get the outputs into a single zip file !!!
A ttf is a true-type font. It is not a picture, but a vectoric character set. You can't convert it to a picture simply with a tool.
If you want to view/manipulate ttf files, you can do this with ttf editing tools, for example fontforge ( http://fontforge.sourceforge.net ).
This may be an old question, but I found the following batch file works with ImageMagick 7:
#ECHO OFF
set f=wingding.TTF
set ps=800
set bg=white
set ext=png
set s=600x600
set alpha=A B C D E F G H I J K L M N O P Q R S T U V W Z Y Z
set num=0 1 2 3 4 5 6 7 8 9
For %%X in (%alpha% %num%) do (
convert -font %f% -pointsize %ps% -size %s% -background %bg% label:%%X
%%X.%ext%)
pause
exit
NOTE: This conversion only works with a limited selection of font characters. It works well for all capital letters. Just install ImageMagick and make sure it is in your environment path. Include "legacy" commands in your installation.
Nothing to do with rendering an individual image on a webpage. Goal is to render the entire webpage save that as a screenshot. Want to show a thumbnail of an HTML file to the user. The HTML file I will be screenshotting will be an HTML part in a MIME email message - ideally I would like to snapshot the entire MIME file but if I can do this to an HTML file I'll be in good shape.
An API would be ideal but an executable is also good.
You need html2ps, and convert from the package ImageMagick:
html2ps index.html index.ps
convert index.ps index.png
The second program produces one png per page for a long html-page - the page layout was done by by html2ps.
I found a program evince-thumbnailer, which was reported as:
apropos postscript | grep -i png
evince-thumbnailer (1) - create png thumbnails from PostScript and PDF documents
but it didn't work on an simple, first test.
If you like to combine multiple pages to a larger image, convert will help you surely.
Now I see, that convert operates on html directly, so
convert index.html index.png
shall work too. I don't see a difference in the output, and the size of the images is nearly identical.
If you have a multipart mime-type email, you typically have a mail header, maybe some pre-html-text, the html and maybe attachments.
You can extract the html and format it seperately - but rendering it embedded might not be that easy.
Here is a file I tested, which was from Apr. 14, so I extract the one mail from the mailfolder:
sed -n "/From - Sat Apr 14/,/From -/p" /home/stefan/.mozilla-thunderbird/k2jbztqu.default/Mail/Local\ Folders-1/Archives.sbd/sample | \
sed -n '/<html>/,/<\/html>/p' | wkhtmltopdf - - > sample.pdf
then I extract just the html-part of that.
wkhtmltopdf needs - - for reading stdin/writing to stdout. The PDF is rendered, but I don't know how to integrate it into your workflow.
You can replace wkhtml ... with
convert - sample.jpg
I'm going with wkhtmltoimage. This worked once correctly set up xvfb. The postscript suggestion did not render correctly and we need img not pdf.
I'm in a situation where I need to accept copied images from a Word (.doc / .docx) document to a spark image on the AIR application. I tried with a sample document with an image embedded inside. When I open it up on Pages on Mac, the copied image pastes perfectly onto the the spark image object via the code below:
var clipboardImage:Bitmap = new Bitmap(Clipboard.generalClipboard.getData(ClipboardFormats.BITMAP_FORMAT) as BitmapData);
clipboardImage.width = fldPicture.width;
clipboardImage.height = fldPicture.height;
fldPicture.source = clipboardImage;
fldPicture is the spark image. This may have been okay but when I sent the AIR application and the same Word document over to a friend who runs Windows and has Microsoft Office 2010, it didn't work. It only seems to work if the copied image from the Word document is pasted to MS Paint then copied again but this time, from the MS Paint.
Sorry if this seems rather confusing, I tried to explain it as much as I could. If anyone can shed some light on this issue, it would really be appreciated.
Mmh I'm afraid it has to do with the way Word handles file formats and so.
Word uses a lot of headers, internal-code / tags only used by itself to recognize objets, text formats, images...
And I suppose the content of the clipboard coming from Word has to be stripped from this headers of some kind before it can be used, thing that Paint automatically do (thing that could explain why it works when getting to Paint before pasting it in your app).
Maybe you could try to put the pasted data into a byte array and try to remove the headers manually before getting it into a Bitmap ?...