Correct img format for browser widget.

[jonathandlynch at gmail.com]

It sounds like the dataURL method costs about a tenth of a second per image, for moderately large images.

I had never tested that, but it's good to know. For my purposes right now, that is not an issue, but it could be for plenty of situations.


Sent from my iPhone

> On Jul 16, 2017, at 11:42 PM, James Hale via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Thank you so much Hermann and Jonathan
> 
> It took me a little time but I worked out what to do after looking at your suggestions.
> 
> The fact that setting the htmltext of the browser widget breaks the img URL's makes sense from a security and logical point of view.
> 
> I then tried Jonathan's technique of using the image data. 
> This worked a treat but for some files was quite slow on my larger files.
> e.g. one html had 200 images. It took some 20 secs for the browser to load.
> 
> So I thought I would try Hermann's later suggesting of just saving the file as an html and setting the URL of the browser to it.
> The conversion from markdown left the img tags in the correct format for a browser to locate the files.
> 
> After finding Trevor's function for correctly URL encoding the file name I was able to successfully load the files into the browser widget and display the images.
> The 200 image file loaded in less than a second which was good.
> 
> The final issue was the varying width of the images.
> I simply loaded an array keyed on the file names with a single value, image width.
> I didn't want any widths greater than 800 pixels so a simply if statement set all widths > 800 to 800
> Then a simple replace loop using the image size array "gimagescale"...
> repeat for each key ikey in gimagescale
> 
>     replace ikey&quote&" " with ikey&quote&" width = "&quote&gimagescale[ikey]&quote in nfile
> 
> end repeat
> 
> and the img tags were in a format I wanted.
> 
> Loading into the browser widget was fast and the images all fitted in the browser's width.
> 
> Setting the htmltext of a field was my first choice. But the html of the converted markdown docs was more than LC's htmltext function could handle.
> And to be honest, the browser's rendering looked better.
> Had the html been simpler, using a field would have been just as fast.
> 
> Anyway, my issue is resolved.
> 
> Thank you both again for your help.
> 
> James
> 
> 
> 
> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode