gnuplot 4.7 hypertext not working with canvas terminal - html

I am using gnuplot 4.7 patch 0.
My data file "test.txt" looks like the following:
0 0 net0
1 1 net1
2 2 net2
3 3 net3
4 5 net4_outlier
5 5 net5
My gnuplot code "script.gp" looks like this:
set term canvas
set termoption enhanced
set label at 0,0 "Origin"
set title 'mouse over points'
plot 'test.txt' using 1:2:3 with labels hypertext point pt 7 ps var lc rgb "black"
Testing:
I tested that canvas is an available terminal by typing terminal and canvas is available in the list. The version of firefox I am using is "Mozilla Firefox 5.0". I have checked that this version is compatible with html 5 canvas element.
I am running the script as:
gnuplot script.gp > canvas.html
I am loading the output html file as:
firefox canvas.html&
Result:
I get a plot, with the 10 points, but the hover label is not working. If I remove hypertext and use normal label, then that is working - labels are printed.
Could someone point out what is the mistake I am making here - I have read that hypertext is supported in gnuplot 4.7 patch 0.
Any help is appreciated.

The hypertext feature is connected to the mousing terminal option, i.e. use
set terminal canvas enhanced mousing
to see the labels on mouse over.
If you don't want the additional coordinate box, then you must just replace the line
<script type="text/javascript">gnuplot.init = function() {};</script>
in the html <header> with
<script src="/absolute/path/to/js/gnuplot_mouse.js"></script>
of course with the correct path to the javascript file (see the path to gnuplot_common.js).
As note: 4.7 is a development version with no patchlevel. Soon, the new stable version 5.0 will appear.

Related

mxClient renders different shapes all as squares

Several weeks ago I have been asked to upgrade a web application based on a very old version of MXGraph library (version 2.4). The application integrated also the 'grapheditor' a sort of demo application evolved later in Diagramly
and then in Draw.io). Recently I completed the more problematic step, the transition from old "grapheditor" to Draw.io, so I am now able to open all the previous diagrams (saved as plain XML), modify and save them consistently.
Ok, this is the nice part. The bad side is the 'read-only' section of the application ,where the users can more or less, only view the graph.
This page is based on the mxClient.js that renders the graph described in the xml through this code:
var graph = new mxGraph(container);
var diagram = mxUtils.parseXml(xml);
var codec = new mxCodec(diagram);
codec.decode(diagram.documentElement, graph.getModel());
graph.fit();
Upgrading the MX library to the last version (3.9.10) the same code works but some shapes are not rendered properly, they appears as squares instead of
circles, ellipses, etc. The two following images are an example of this misbehavior
Graph in the draw.io:
Same graph rendered by mxClient:
After some tries I discovered that the old mxClient is able to render the same graph perfectly (as draw.io does) so I think there have to be something wrong (or missing) in my code or mxGraph installation/configuration.
As a temporary workaround I can keep in place the old version of mxGraph but obviously I'd like to use the new one.
Can someone give me an hint on this? Any help would be very appreciated.
The tape shape isn't part of core mxGraph, it's part of the GraphEditor example, in the additional shapes JavaScript.
If you look at the style of the ellipse, it's probably not the one in the core, most likely another one from Shapes.js.
Either pull in shapes.js, or use the viewer in draw.io.

Forge Viewer select element by tapping screen not working correctly on Surface Pro using IE 11 (via cordova)

Using Surface pro touch screen to select element in viewer works sometimes other times it seems to translate to a rotate/zoom action. In this case the viewer rotates/moves and the element is NOT selected.
When logging the events there are plenty of mouse down/up events along with mouse moves when it doesnt work. When select does work a single click event occurs.
Double click seems to work ok.
Zoom/rotate etc using standard tools works ok.
Using the keyboard cover touch pad that you can get for the Surface pro to move and click works as expected and the element is selected.
Running same application on a GETAC Windows 10 ruggadised tablet the select element works correctly so it seems related to the Surface Pro.
Unable to change browsers as cordova apps use IE11 on windows and that is currently fixed.
The only solution i can think of for the moment is to remove the standard navigation tools completely (somehow) and recreate a select mode tool that would ignore any mouse moves and use button down event to select element.
Any suggestions on how to fix this?
Tech Details:
Windows 10 Pro,
Surface Pro,
Browser: IE11,
Viewer version 2.11,
Other: WINJS81 cordova application
Thanks for any help
We've had problems with touch events on the Surface Pro in the past. It sounds like the edges of the touch screen are overly sensitive and are triggering extra touch points.
Does the problem happen if you are holding the device up, gripping with one hand, and using your other hand to touch/select a 3D object ?
Could you try doing a selection again, but this time, make sure you other hand is not holding the edge of the screen? (Perhaps place the device on the surface of a desk, so you are not holding it up)
Found a fix to this issue. In viewer3D in the base toolcontroller there is line
var kClickThreshold = 2;
This value is used further down in code to determine if singleClick has occured. It does it by comparing XY on down and up events.
var deltaX = _downX - event.canvasX;
var deltaY = _downY - event.canvasY;
_downX = -1;
_downY = -1;
if( Math.abs(deltaX) <= kClickThreshold && Math.abs(deltaY) <= kClickThreshold )
_this.handleSingleClick( event );
If movement is above this threshold it does not trigger singleClick if below it does.
Did testing and increasing the value to around 5-7 means that the selection of elements worked consistently. (there is still a minor rotate or zoom at same time as select occurs but I assume that this would be another part of viewer that would need adjusting)
Unfortunately it does require edit of viewer code but easy enough. I added code to overwrite standard value if external variable existed.
Would be nice for future viewer dev if more of these types of properties be exposed so that direct edit of code is not required.
Still it is good to have the source code to be able to debug at this level.
At a guess the Surface Pro 4 must have a more sensitive touch system or it could just be related to IE11 as well.

How can you tell whether the file you've downloaded in PNG-8, PNG-24, or PNG-32? [duplicate]

Is there a way to find out if a PNG is the 8 or 24 type? Ive tried with windows, fireworks and photoshop but I cant figure this out.
Thanks
The quickest way is to just peek at bytes 24 and 25 in the PNG file. They contain the bit depth (1, 2, 4, 8, or 16) and color type
0: gray,
2: rgb,
3: indexed (colormapped),
4: gray+alpha, or
6: rgba.
If the bitdepth is 8 and the colortype is 3 you have a PNG8, and if the bitdepth is 8 and colortype is 2 you have a PNG24.
On a *nix platform, the "file" command will do this for you, e.g.,
A PNG8:
glenn.rp> file logo.png
logo.png: PNG image data, 640 x 480, 8-bit colormap, non-interlaced
A PNG24:
glenn.rp> file rose.png
rose.png: PNG image data, 70 x 46, 8-bit/color RGB, non-interlaced
Open it in Photoshop and check what's written on the top bar. If it says "index", then it has been saved as 8-bit PNG, if it says "RGB/8" then your PNG is a 32-bit one.
Alternatively you can open Image/Mode menu and for an 8-bit one it would be "Indexed color", while for a 32-bit one - "RGB color".
Another really quick way to tell without opening the file is to see if there is any smooth gradient transparencies in the image. 8 bit pngs don't have transparent gradients - it's either fully opaque or fully transparent (nothing in between).
(For those who don't have Photoshop)
Howto identify bit depth for image files on Windows:
*Right click* image file > Properties > Details > Bit depth
In a Linux based environment, one could use the file command.
$ file image-1.png
PNG image data, 3840 x 2160, 8-bit/color RGBA, non-interlaced
So based on the output above, image-1.png has four channels (RGBA - red, green, blue, alpha). 8-bit per channel which sums up to 32 bits.
$ file image-2.png
PNG image data, 3840 x 2160, 8-bit/color RGB, non-interlaced
image-2.png has only 3 channels (RGB). It does not have the alpha channel. So it is in PNG‑24 format.
There's also identify command from ImageMagick that could use to retrieve more detailed information about image files.
sudo apt-get install imagemagick
identify -verbose image.png
Just add the 'Bit Depth' column and it should show you the Bit depth right in the details view in file explorer.
This way for Mac Os
Right Click > Get Info
My image appears to be 32 bit in total.
Color space: RGB (3 * 8 bit = 24 bit)
Alpha channel: Yes (8 bit)
Result:
24 + 8 = 32 bit

ghostscript ps2ps crops document adding some margins/ borders

I feel noob on this one... But here it comes:
Let's take a Vector program with a PS exporter (with no font sub setting: important to change text dynamically in the future) more specifically the Inkscape version 0.46.
Document size A4 and lets draw some lines very close to the border and a simple text, after that you export your ps as noborder.ps:
Everything is really fine! What is on the first lines of postscript file?
%!PS-Adobe-3.0
%%Creator: 0.46
%%Pages: 1
%%Orientation: Portrait
%%BoundingBox: 0 0 596 842
%%HiResBoundingBox: 0 0 596 842
%%DocumentMedia: plain 596 842 0 () ()
%%EndComments
%%Page: 1 1
Now we need to generate a PS file from this PS file (Why? Some new fonts that cannot be uploaded to the printer and dynamically text are changed. PS2PS is a good choice to embed fonts and other elements prior to printing). Let's use ps2ps from ghostscript 8.7.
user#server:/$ ps2ps noborder.ps whyborder.ps
Very good! No errors on running... But... What? BORDERS? MARGINS? CROPPING?
Lets look at the whyborder.ps header:
%!PS-Adobe-3.0
%%Pages: (atend)
%%BoundingBox: 5 6 587 792
%%HiResBoundingBox: 5.000000 6.791406 586.732813 792.000000
%.........................................
%%Creator: GPL Ghostscript 870 (pswrite)
%%CreationDate: 2015/09/09 16:09:24
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
%%EndComments
%%BeginProlog
% This copyright applies to everything between here and the %%EndProlog:
Why is the BoundingBox changed??? Why add borders, margins, cropping?
I have tested options like "-dEPScrop", papersize... But the cropping remains... Why???
Firstly, stop using an ancient version of Ghostscript! 8.70 is now 6 years old, the current version is 9.16 (shortly to be superceded by 9.18).
Secondly, when experimenting like this do not use a script, use the command line directly. The device being used in the archaic version of GHostscript was pswrite, which was a very poor implementation and only supported level 1 output. The current code uses the ps2write device which is a much more powerful and flexible solution.
Note that in all cases running the input through Ghostscript does not 'embed fonts' or 'edit' or 'compress' the original. What happens is that your input is interpreted to produce graphics primitives which are fed to the device API, the device in question then processes the primitives. For a rendering device this means calling the graphics library to render the primitive to the canvas. For a high level device it means re-emitting the primitive , for example as a PDF operation.
ANY such processing brings inherent risks of approximation, the pswrite device was even worse in that much of the content was rendered to images. So in general it really doesn't embed new fonts, it just embeds pictures of the glyphs. This scales really badly and because the bounding box depends on the resolution can result in signficant inaccuracies.
You should really avoid doing ths unless there is no alternative. If you really must do it, be prepared to accept compromises, do not use archaic versions of Ghostscript and don't use the crappy old pswrite device.
Thank you KenS;
By upgrading the ghostscript to version 9.16 and using the following command everything was fine:
user#server:/$ ps2ps -sPAPERSIZE=a4 noborder.ps whyborder916.ps
This is a old and stable system (PHP/Bash/Ghostscript/CUPS), used for many years as a factory labeling system with old postscript printers also. More recently there was the need to change font style; ps2ps was the best choice to "embed" the glyphs and barcodes (postcript language) that dynamically change with the production line and packaging without need to change the printers (different models from different manufacturers). Since PostScript is a language with few changes in years, never crossed my mind to change the GS version.
At this point this is a real money saver! Thanks again!

No Dynamic Text will correctly show, why?

I am learning rudementary flash, and have a book in hand; but am beginning to wonder if there is something wrong with the program or my computer. The following should be simple but only gives me nothing in the dynamic text box or just pieces of letters.
Frame 1
var amount:Number = 1;
Frame 2
howmuch.text = String (amount);
and....nothing ever shows....like ever. I've used this in a simple loop according to the actionscript 3.0 lesson including an amount++ function to make a simple counter.
I'm trying to get each concept and build on it, but have been here at lesson one for days.
using Adobe Flash CC on an iMac I bought here in 2013 running Mountain Lion.
Help please.
Because your text field is a dynamic one you may need to embed the font. Also check if the text color is not the same as the color of the background.