PHP Library to Generate xdot Files From dot Files - php

Apologies in advance is I'm misusing terminology, and corrections are appreciated. I'm fascinated by directed graphs, but I never has the math/cs background to know what they're really about, I just like the tech because it makes useful diagrams.
I'm trying to create a web application feature that will render a dynamic directed graph to the browser. I recently discovered Canviz, which is a cavas based xdot renderer, which I'd like to use.
Canviz is awesome, but it renders xdot files, which (appear?) to contain all the complicated positioning logic
/* example xdot file */
digraph abstract {
graph [size="6,6"];
node [label="\N"];
graph [bb="0,0,1250,612",
_draw_="c 9 -#ffffffff C 9 -#ffffffff P 4 0 -1 0 612 1251 612 1251 -1 ",
xdotversion="1.2"];
S1 [pos="464,594", width="0.75", height="0.5", _draw_="c 9 -#000000ff e 464 594 27 18 ", _ldraw_="F 14.000000 11 -Times-Roman c 9 -#000000ff T 464 588 0 15 2 -S1 "];
10 [pos="409,522", width="0.75", height="0.5", _draw_="c 9 -#000000ff e 409 522 27 18 ", _ldraw_="F 14.000000 11 -Times-Roman c 9 -#000000ff T 409 516 0 15 2 -10 "];
S1 -> 10 [pos="e,421.43,538.27 451.52,577.66 444.49,568.46 435.57,556.78 427.71,546.5", _draw_="c 9 -#000000ff B 4 452 578 444 568 436 557 428 546 ", _hdraw_="S 5 -solid c 9 -#000000ff C 9 -#000000ff P 3 430 544 421 538 425 548 "];
}
The files I'm generating with my application are dot files, which contain none of this positioning logic
digraph g {
ranksep=6
node [
fontsize = "16"
shape = "rectangle"
width =3
height =.5
];
edge [
];
S1 -> 10
}
I'm looking for a PHP library that can convert my dot file into an xdot file that can be consumed by Canviz. I realize that the command line program dot can do this, but this is for a redistributable PHP web application, and I'd prefer to avoid any binaries as dependencies.
My core problem: I'm generating dot files based on simple directed relationships, and I want to display the visual graph to end users in a browser. I'd like to do this without having to rely on the presence of a particular binary program on the server. I think the best solution for this is Canviz+PHP to generate xdot files. I'm looking for a PHP library that can do this. However, I'm more than open to other solutions.

Have you looked at Image_GraphViz ? It's really just a wrapper for the binary, but from the look of things, I don't think you'll find something better and this at least keeps you from having to do direct command line calls from your PHP script.
$dot_obj = new Image_GraphViz();
$dot_obj -> load('path/to/graph.gv');
$xdot = $dot_obj -> fetch('xdot');

Related

Exporting a dxf file with a ellipse in php

for a project we need to export some shapes as a .dxf file using the php DXFwriter (https://github.com/digitalfotografen/DXFwriter) which sadly does not include ellipses. We've used polylines instead by now but with hundreds of single points it was not good for our purpose.
We now wanted to use the ellipse entity but if we just add a ellipse to our entities section AutoCAD is not able to open the .dxf file. Do we have to add some lines to one of the other sections to bring ellipses to work or do you have some other ideas how to solve this problem?
The entities section:
0
SECTION
2
ENTITIES
0
ELLIPSE
5
262
330
1F
100
AcDbEntity
8
0
100
AcDbEllipse
10
1927.933413526791
20
2355.552659681358
30
0.0
11
1694.611795869434
21
-112.6281645577583
31
0.0
210
0.0
220
0.0
230
1.0
40
0.2345744769758316
41
0.0
42
6.283185307179586
0
ENDSEC
Greetings
Joe
Solution:
In the end we've decided to write our own DXF export library which is able to export valid R13 DXF files. It's open source so if anyone will have similar problems maybe https://github.com/enjoping/DXFighter is something for you.
A DXF file with only an ENTITIES section is considered by AutoCAD to be a R12 format file and cannot contains entity type added after this release, like ELLIPSE and LWPOLYLINE. You cannot omit other sections, because for R13 and newest files, there is an audit step which check if the file is valid.
From my experiments, it seems to be very difficult to build a valid post R12 DXF file.

why golang and php gzip results are different [duplicate]

Firstly, my Java version:
string str = "helloworld";
ByteArrayOutputStream localByteArrayOutputStream = new ByteArrayOutputStream(str.length());
GZIPOutputStream localGZIPOutputStream = new GZIPOutputStream(localByteArrayOutputStream);
localGZIPOutputStream.write(str.getBytes("UTF-8"));
localGZIPOutputStream.close();
localByteArrayOutputStream.close();
for(int i = 0;i < localByteArrayOutputStream.toByteArray().length;i ++){
System.out.println(localByteArrayOutputStream.toByteArray()[i]);
}
and output is:
31
-117
8
0
0
0
0
0
0
0
-53
72
-51
-55
-55
47
-49
47
-54
73
1
0
-83
32
-21
-7
10
0
0
0
Then the Go version:
var gzBf bytes.Buffer
gzSizeBf := bufio.NewWriterSize(&gzBf, len(str))
gz := gzip.NewWriter(gzSizeBf)
gz.Write([]byte(str))
gz.Flush()
gz.Close()
gzSizeBf.Flush()
GB := (&gzBf).Bytes()
for i := 0; i < len(GB); i++ {
fmt.Println(GB[i])
}
output:
31
139
8
0
0
9
110
136
0
255
202
72
205
201
201
47
207
47
202
73
1
0
0
0
255
255
1
0
0
255
255
173
32
235
249
10
0
0
0
Why?
I thought it might be caused by different byte reading methods of those two languages at first. But I noticed that 0 can never convert to 9. And the sizes of []byte are different.
Have I written wrong code? Is there any way to make my Go program get the same output as the Java program?
Thanks!
First thing is that the byte type in Java is signed, it has a range of -128..127, while in Go byte is an alias of uint8 and has a range of 0..255. So if you want to compare the results, you have to shift negative Java values by 256 (add 256).
Tip: To display a Java byte value in an unsigned fashion, use: byteValue & 0xff which converts it to int using the 8 bits of the byte as the lowest 8 bits in the int. Or better: display both results in hex form so you don't have to care about sign-ness...
Even if you do the shift, you will still see different results. That might be due to different default compression level in the different languages. Note that although the default compression level is 6 in both Java and Go, this is not specified and different implementations are allowed to choose different values, and it might also change in future releases.
And even if the compression level would be the same, you might still encounter differences because gzip is based on LZ77 and Huffman coding which uses a tree built on frequency (probability) to decide the output codes and if different input characters or bit patterns have the same frequency, assigned codes might vary between them, and moreover multiple output bit patterns might have the same length and therefore a different one might be chosen.
If you want the same output, the only way would be (see notes below!) to use the 0 compression level (not to compress at all). In Go use the compression level gzip.NoCompression and in Java use the Deflater.NO_COPMRESSION.
Java:
GZIPOutputStream gzip = new GZIPOutputStream(localByteArrayOutputStream) {
{
def.setLevel(Deflater.NO_COMPRESSION);
}
};
Go:
gz, err := gzip.NewWriterLevel(gzSizeBf, gzip.NoCompression)
But I wouldn't worry about the different outputs. Gzip is a standard, even if outputs are not the same, you will still be able to decompress the output with any gzip decoders whichever was used to compress the data, and the decoded data will be exactly the same.
Here are the simplified, extended versions:
Not that it matters, but your codes are unneccessarily complex. You could simplify them like this (these versions also include setting 0 compression level and converting negative Java byte values):
Java version:
ByteArrayOutputStream buf = new ByteArrayOutputStream();
GZIPOutputStream gz = new GZIPOutputStream(buf) {
{ def.setLevel(Deflater.NO_COMPRESSION); }
};
gz.write("helloworld".getBytes("UTF-8"));
gz.close();
for (byte b : buf.toByteArray())
System.out.print((b & 0xff) + " ");
Go version:
var buf bytes.Buffer
gz, _ := gzip.NewWriterLevel(&buf, gzip.NoCompression)
gz.Write([]byte("helloworld"))
gz.Close()
fmt.Println(buf.Bytes())
NOTES:
The gzip format allows some extra fields (headers) to be included in the output.
In Go these are represented by the gzip.Header type:
type Header struct {
Comment string // comment
Extra []byte // "extra data"
ModTime time.Time // modification time
Name string // file name
OS byte // operating system type
}
And it is accessible via the Writer.Header struct field. Go sets and inserts them, while Java does not (leaves header fields zero). So even if you set compression level to 0 in both languages, the output will not be the same (but the "compressed" data will match in both outputs).
Unfortunately the standard Java does not provide a way/interface to set/add these fields, and Go does not make it optional to fill the Header fields in the output, so you will not be able to generate exact outputs.
An option would be to use a 3rd party GZip library for Java which supports setting these fields. Apache Commons Compress is such an example, it contains a GzipCompressorOutputStream class which has a constructor which allows a GzipParameters instance to be passed. This GzipParameters is the equvivalent of the gzip.Header structure. Only using this would you be able to generate exact output.
But as mentioned, generating exact output has no real-life value.
From RFC 1952, the GZip file header is structured as:
+---+---+---+---+---+---+---+---+---+---+
|ID1|ID2|CM |FLG| MTIME |XFL|OS | (more-->)
+---+---+---+---+---+---+---+---+---+---+
Looking at the output you've provided, we have:
| Java | Go
ID1 | 31 | 31
ID2 | 139 | 139
CM (compression method) | 8 | 8
FLG (flags) | 0 | 0
MTIME (modification time) | 0 0 0 0 | 0 9 110 136
XFL (extra flags) | 0 | 0
OS (operating system) | 0 | 255
So we can see that Go is setting the modification time field of the header, and setting the operating system to 255 (unknown) rather than 0 (FAT file system). In other respects they indicate that the file is compressed in the same way.
In general these sorts of differences are harmless. If you want to determine if two compressed files are the same, then you should really compare the decompressed versions of the files though.

Complicated: Error uncompressing data from a packet stream zlib

I have a incoming stream that is compressed using the zlib functions, but I cannot tell the ending of the compressed data, so am having a lot of trouble getting the data out.
I also have a snippet of the source code where it is being uncompressed in AS3 flash, which should have been enough for me to figure it out, but I am at a loss.
Two files included:
http://falazar.com/projects/irnfll/version4/test//stackoverflow/as3_code.as.txt
http://falazar.com/projects/irnfll/version4/test//stackoverflow/bin_data_file
Snippet of the binary data, and what I know:
00 00 02 34 2c 02 31 78 5e ed dc cd 6e da 40 a5
21 19 40 f5 f2 c4 b7 e9 18 85 e1 5b 89 66 3d 42
31 95 90 cd 15 74 99 55 37 51 14 59 c9 a8 8c 54
0234 appears to be a size marker - 564
2c = 44, the code to match as3 COMMAND_WORLD_DATA, that is ok
0231 another size marker, always 3 smaller than above
785e - is the header marker for the zlib compress weakest compression, ZLIB_ENCODING_DEFLATE level 4
Later there is also a 789c which is another larger compressed block
I need to uncompress the two of these to move forward in project, thank you for your help.
There is also mention in the script of bigendian conversion, and am I not sure if I need to handle that.
I have written a couple scripts to try and solve this, including a php snippet that chops off the end until and loops trying to uncompress with no luck.
falazar.com/projects/irnfll/version4/test//stackoverflow/php_test.php.txt
Ideal solution in php or c#, but anything I can see that works will translate into another language easy enough.
(Using Free hex editor nero to view the binary)
You mean zlib.
Use PHP's gzuncompress() starting at each zlib header (e.g. 789c).

Regular expression works on some servers and not others

I'm having trouble debugging a regular expression. First, the code (this is the complete file... sorry for the lack of line breaks -- see http://pastebin.com/h5CeiY5F for a pastebin):
<?php
$matches = null;
$returnValue = preg_match('#" FirstDownType="[A-Z][0-9]+"/><Play PlayDescription="Penalty[^<]+/>#', '<Play DownDistanceYardline="3-1-GB 7" EarnedFirstDown="False" PlayDescription="(3:40) 71-C.Brown reported in as eligible. 28-M.Ingram left guard to GB 7 for no gain (94-J.Wynn; 95-H.Green)."/><Play DownDistanceYardline="4-1-GB 7" EarnedFirstDown="False" PlayDescription="(3:10) 9-D.Brees pass incomplete short left to 23-P.Thomas."/><Play Header="Green Bay Packers at 3:02"/><Play DownDistanceYardline="1-10-GB 7" EarnedFirstDown="False" PlayDescription="(3:02) 44-J.Starks right tackle to GB 11 for 4 yards (94-C.Jordan)."/><Play DownDistanceYardline="2-6-GB 11" EarnedFirstDown="False" PlayDescription="(2:26) 12-A.Rodgers pass deep right to 85-G.Jennings pushed ob at GB 33 for 22 yards (33-J.Greer)." FirstDownType="P17"/><Play PlayDescription="Penalty on NO-33-J.Greer, Defensive Pass Interference, declined."/><Play DownDistanceYardline="1-10-GB 33" EarnedFirstDown="True" PlayDescription="(2:01) (Shotgun) 12-A.Rodgers pass short left to 85-G.Jennings to GB 47 for 14 yards (21-P.Robinson)." FirstDownType="P18"/><Play DownDistanceYardline="1-10-GB 47" EarnedFirstDown="True" PlayDescription="(1:22) 12-A.Rodgers pass short right to 87-J.Nelson pushed ob at NO 44 for 9 yards (27-M.Jenkins)."/><Play DownDistanceYardline="2-1-NO 44" EarnedFirstDown="False" PlayDescription="(:47) 44-J.Starks right tackle to NO 42 for 2 yards (51-J.Vilma; 94-C.Jordan)." FirstDownType="R19"/><Play DownDistanceYardline="1-10-NO 42" EarnedFirstDown="True" PlayDescription="(:07) 25-R.Grant right tackle to NO 40 for 2 yards (51-J.Vilma, 58-S.Shanle)."/><QuarterSummary Team="New Orleans Saints" Score="27" TimeOfPossession="10:47" FirstDownsRushing="3" FirstDownsPassing="5" FirstDownsPenalty="1" FirstDownsTotal="9" ThirdDownEfficiency="1/3" FourthDownEfficiency="0/1"/><QuarterSummary Team="Green Bay Packers" Score="35" TimeOfPossession="4:13" FirstDownsRushing="1" FirstDownsPassing="2" FirstDownsPenalty="0" FirstDownsTotal="3" ThirdDownEfficiency="0/1" FourthDownEfficiency="0/0"/>', $matches);
print_r($matches);
When I run this on several sandboxes (like http://sandbox.onlinephpfunctions.com/ or functions-online.com/preg_match.html ), it returns:
Array ( [0] => " FirstDownType="P17"/><Play PlayDescription="Penalty on NO-33-J.Greer, Defensive Pass Interference, declined."/> )
That's the expected output I'm looking for.
However, when I run it on my server (and I've tested it on two different servers), I get:
Array ( [0] => " FirstDownType="P17"/> )
All I can think of is that preg_match changed between PHP 5.3.10 (the version on the sandbox) and PHP 5.3.6 (our version), or that our Ubuntu version is misconfigured?
I'd really appreciate any help. Thanks!
Do you need to match this using a regex? How about using an XML parser instead?
Try using SimpleXML to get the node(s) you need.
$sXML = new SimpleXMLElement('<xml>'.$xml.'</xml>');
Then you can use XPath to find the element(s) you need.
$play = $sXML->xpath('//Play[starts-with(#PlayDescription, "Penalty")]/preceding-sibling::Play[#FirstDownType]');
This will select the Play element preceding the Play element that has a PlayDescription starting with "Penalty".
DEMO: http://codepad.viper-7.com/ECQKcB

CJK White Space Characters Disappearing

I have a PHP script which fetches data from Salesforce via the Salesforce API and writes the output to a file using file_put_contents. The data is a mixture of Korean characters and English characters.
When I run the script on a box (1) running Red Hat Enterprise Linux ES release 4 (Nahant Update 8) with PHP 5.2.8 and a similar box (2) running PHP 5.3.6 the spaces in between the Korean characters disappear.
e.g. (Using K to represent a Korean character and E to represent an English character)
EEEEEEEEK KKK KKKK EEE KKKK is appearing as EEEEEEEEKKKKKKKK EEE KKKK
However when I run the script on a box (3) running CentOs with PHP 5.3.5 or on (4) my local windows machine with PHP 5.3.6 the text in the file is correct.
Can anyone suggest what the problem might be?
EDIT - Originally I was accessing the php script via a browser however to (hopefully) simplify the problem I am currently storing the output in a text file and downloading it to my windows machine.
EDIT - Hex version
Original text - CFD란 무엇입니까?
Hex from (1) - 43 46 44 eb 9e 80 eb ac b4 ec 97 87 ec 9e 85 eb 8b 88 ea b9 8c 3f
Hex from (3) - 43 46 44 eb 9e 80 20 eb ac b4 ec 97 87 ec 9e 85 eb 8b 88 ea b9 8c 3f
EDIT - Code used to select text (with user, pass, table, id and path omitted)
<?php
ini_set("soap.wsdl_cache_enabled", "0");
require_once ("../soapclient/SforcePartnerClient.php");
require_once ("../soapclient/SforceHeaderOptions.php");
$partner_wsdl = "../soapclient/new-partner.wsdl.xml";
$client = new SforcePartnerClient();
$client->createConnection($partner_wsdl);
$loginResult = $client->login('--user--', '--pass--');
$query = "Select Name FROM --table-- WHERE Id = '--id--'";
$response = $client->query($query);
echo'<pre>';print_r($response);echo'</pre>';
$queryResult = new QueryResult($response);
foreach ($queryResult->records as $qr) {
$content = $qr->fields->Name;
file_put_contents('--path--',$content);
}
?>
After more research I discovered a function in the SforcePartnerClient.php
$QueryResult = $this->sforce->query(array ('queryString' => $query))->result;
is returning different values depending on the box used.
Box 1 and 2:
<sf:Name>CFD란 무엇입니까?</sf:Name>
Box 3 and 4:
<sf:Name>CFD란 무엇입니까?</sf:Name>
When this is combined with / parsed / converted using the XML parser (later in the file) and WSDL file the XML parser strips any white space that occurs between consecutive &#xxxxx; s - I believe this is related to a bug https://bugs.php.net/bug.php?id=33240 to avoid this I suggest commenting out line 364 of SforcePartnerClient.php
xml_parser_set_option( $parser, XML_OPTION_SKIP_WHITE, 1 );
Unfortunately I do not know if this will have any adverse effects on other code using SforcePartnerClient.php.

Categories