I have graphviz installed on a linux VM. I am automatically converting .apt into .dot files using APT. I draw these with graphviz and the dot command. But it keeps showing the xlabels, which are set automatically by APT. Is there a way to surpress these xlabels, so they dont show ?
-Gforcelabels=false didn't work and i could not change the labels with -Exlabel
dot -Nxlabel="" -Exlabel="" -T... should(?) work, but it does not! I consider this a bug, not a feature.
This does work:
gvpr -c 'E{$.xlabel=""}N{$.xlabel=""}' file.dot |dot -Tsvg >file.svg
Related
Does anyone know a tool for showing the path from one file to another? Ie, if my css file is in:
/User/foo/bar/source/assets/myscreen
and my image is in:
/User/foo/bar/gamethings/smallimages
How can I quickly, without having to count the file levels (which is simple, but tedious, and has to be done often), generate the path from the css to the image?
First, get realpath(1) from GNU Coreutils. Then:
$ realpath --relative-to=/User/foo/bar/source/assets/myscreen /User/foo/bar/gamethings/smallimages
../../../gamethings/smallimages
RGL supports writing DOT files from a graph, is it possible to create a graph from a DOT file?
(Obviously I can parse the DOT file myself and create a graph, but I'm wondering if this functionality exists already).
First you have to install graphviz which gives you the 'dot' command.
Then you can run
dot -Tpng graph.dot > output.png
but I found that after installing dot the rgl method write_to_graphic_file automatically writes the image if you do something like
graph_obj.write_to_graphic_file('png')
Okay so here is what I want to do. I want to add a print option that prints whatever the user's document is to a PDF and adds some headers before sending it off to a device.
I guess my questions are: how do I add a virtual "printer" driver for the user that will launch the application I've been developing that will make the PDF (or make the PDF and launch my application with references to the newly generated PDF)? How do I interface with CUPS to generate the PDF? I'm not sure I'm being clear, so let me know if more information would be helpful.
I've worked through this printing with CUPS tutorial and seem to get everything set up okay, but the file never seems to appear in the appropriate temporary location. And if anyone is looking for a user-end PDF-printer, this cups-pdf-for-mac-os-x is one that works through the installer, however I have the same issue of no file appearing in the indicated directory when I download the source and follow the instructions in the readme. If anyone can get either of these to work on a mac through the terminal, please let me know step-by-step how you did it.
The way to go is this:
Set up a print queue with any driver you like. But I recommend to use a PostScript driver/PPD. (A PostScript PPD is one which does not contain any *cupsFilter: ... line.):
Initially, use the (educational) CUPS backend named 2dir. That one can be copied from this website: KDE Printing Developer Tools Wiki. Make sure when copying that you get the line endings right (Unix-like).
Commandline to set up the initial queue:
lpadmin \
-p pdfqueue \
-v 2dir:/tmp/pdfqueue \
-E \
-P /path/to/postscript-printer.ppd
The 2dir backend now will write all output to directory /tmp/pdfqueue/ and it will use a uniq name for each job. Each result should for now be a PostScript file. (with none of the modifications you want yet).
Locate the PPD used by this queue in /etc/cups/ppd/ (its name should be pdfqueue.ppd).
Add the following line (best, near the top of the PPD):
*cupsFilter: "application/pdf 0 -" (Make sure the *cupsFilter starts at the very beginning of the line.) This line tells cupsd to auto-setup a filtering chain that produces PDF and then call the last filter named '-' before it sends the file via a backend to a printer. That '-' filter is a special one: it does nothing, it is a passthrough filter.
Re-start the CUPS scheduler:sudo launchctl unload /System/Library/LaunchDaemons/org.cups.cupsd.plist
sudo launchctl load /System/Library/LaunchDaemons/org.cups.cupsd.plist
From now on your pdfqueue will cause each job printed to it to end up as PDF in /tmp/pdfqueue/*.pdf.
Study the 2dir backend script. It's simple Bash, and reasonably well commented.
Modify the 2dir in a way that adds your desired modifications to your PDF before saving on the result in /tmp/pdfqueue/*.pdf...
Update: Looks like I forgot 2 quotes in my originally prescribed *cupsFilter: ... line above. Sorry!
I really wish I could accept two answers because I don't think I could have done this without all of #Kurt Pfeifle 's help for Mac specifics and just understanding printer drivers and locations of files. But here's what I did:
Download the source code from codepoet cups-pdf-for-mac-os-x. (For non-macs, you can look at http://www.cups-pdf.de/) The readme is greatly detailed and if you read all of the instructions carefully, it will work, however I had a little trouble getting all the pieces, so I will outline exactly what I did in the hopes of saving someone else some trouble. For this, the directory with the source code is called "cups-pdfdownloaddir".
Compile cups-pdf.c contained in the src folder as the readme specifies:
gcc -09 -s -lcups -o cups-pdf cups-pdf.c
There may be a warning: ld: warning: option -s is obsolete and being ignored, but this posed no issue for me. Copy the binary into /usr/libexec/cups/backend. You will likely have to the sudo command, which will prompt you for your password. For example:
sudo cp /cups-pdfdownloaddir/src/cups-pdf /usr/libexec/cups/backend
Also, don't forget to change the permissions on this file--it needs root permissions (700) which can be changed with the following after moving cupd-pdf into the backend directory:
sudo chmod 700 /usr/libexec/cups/backend/cups-pdf
Edit the file contained in /cups-pdfdownloaddir/extra/cups-pdf.conf. Under the "PDF Conversion Settings" header, find a line under the GhostScript that reads #GhostScript /usr/bin/gs. I did not uncomment it in case I needed it, but simply added beneath it the line Ghostscript /usr/bin/pstopdf. (There should be no pre-cursor # for any of these modifications)
Find the line under GSCall that reads #GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePage\
s=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite \
-f %s Again without uncommenting this, under this I added the line GSCall %s %s -o %s %s
Find the line under PDFVer that reads #PDFVer 1.4 and change it to PDFVer, no spaces or following characters.
Now save and exit editing before copying this file to /etc/cups with the following command
sudo cp cups-pdfdownloaddir/extra/cups-pdf.conf /etc/cups
Be careful of editing in a text editor because newlines in UNIX and Mac environments are different and can potentially ruin scripts. You can always use a perl command to remove them, but I'm paranoid and prefer not to deal with it in the first place.
You should now be able to open a program (e.g. Word, Excel, ...) and select File >> Print and find an available printer called CUPS-PDF. Print to this printer, and you should find your pdfs in /var/spool/cups-pdf/yourusername/ by default.
*Also, I figured this might be helpful because it helped me: if something gets screwed up in following these directions and you need to start over/get rid of it, in order to remove the driver you need to (1) remove the cups-pdf backend from /usr/libexec/cups/backend (2) remove the cups-pdf.conf from /etc/cups/ (3) Go into System Preferences >> Print & Fax and delete the CUPS-PDF printer.
This is how I successfully set up a pdf backend/filter for myself, however there are more details, and other information on customization contained in the readme file. Hope this helps someone else!
I'm using nano on a server via ssh; on that system, nano doesn't have syntax color enabled by default. So I copied these nanosyntax files (for alternative, see also #CraigBarnes' answer) on the server, and had set up ~/.nanorc as:
include "~/nanosyntax/syntax-nanorc/php.nanorc"
include "~/nanosyntax/syntax-nanorc/php2.nanorc"
include "~/nanosyntax/syntax-nanorc/sh.nanorc"
include "~/nanosyntax/syntax-nanorc/python.nanorc"
include "~/nanosyntax/syntax-nanorc/html.nanorc"
include "~/nanosyntax/syntax-nanorc/perl.nanorc"
include "~/nanosyntax/syntax-nanorc/ruby.nanorc"
include "~/nanosyntax/syntax-nanorc/js.nanorc"
Now, this is the thing; if I just call:
nano somefile.php
... no php syntax coloring is done. If I try to force:
nano --syntax=php somefile.php
... still no syntax coloring (shown as plain text). However, if I do:
nano ~/.nanorc
... then I do get syntax coloring (that corresponds to .nanorc type file) ?!
So obviously, syntax coloring as such works (i.e. shell and nano are capable of it) - except, it seems to be ignored for some languages, like in this case php ?!
So, does anyone know what is going on - and how could I get syntax coloring also for php files?
Thanks,
Cheers!
I just ran into the same problem, and I fiddled around a bit with the includes to find the error. Surprisingly, turns out that changing the inclusion order fixed the issue:
This works:
include "~/.nano/nanorc.nanorc"
include "~/.nano/sh.nanorc"
# more includes...
This fails to highlight sh files:
include "~/.nano/sh.nanorc"
include "~/.nano/nanorc.nanorc"
# more includes...
So I guess it's probably a bug (in nano 2.2.2; worked fine in nano 2.1.7)
Hm... well, it seems there has been an upgrade on that server I was using; originally, nano didn't have syntax coloring by default, which is why I used my own separate ~/.nanorc.
Now, however, on the upgraded server, nano seems to work with php syntax coloring by default - and me having my own separate ~/.nanorc seems to have conflicted; because, once I commented all the entries in the private ~/.nanorc (with an #), php syntax coloring was back!!
Whowouldathunkit ?! :)
Cheers!
EDIT: Just to add a couple of notes about nano:
As noted above, syntax coloring is forced with --syntax switch; to see which syntaxes are available:
grep 'include' /etc/nanorc | # find lines containing 'include' in nanorc
grep -v '^#' | # don't process lines that start with '#'
sed 's_.*/\(.*\)\.nanorc"_\1_' # extract plain filenames
Result of this command is something like:
nanorc
c
css
debian
gentoo
html
...
So to force "nanorc" syntax coloring, you use:
nano --syntax=nanorc /usr/share/nano/nanorc.nanorc
.. or forcing "bash" shell script syntax coloring (especially useful with bashrc) would be:
nano --syntax=sh ~/.bashrc
Those "nanosyntax" files on Google Code are nearly as bad as ones that come with nano by default.
nano's highlighting engine is more basic than something with nested contexts (e.g. GtkSourceView) but you don't have to settle for crappy highlighting:
https://github.com/craigbarnes/nanorc
Okay guys, you're my only help :)
I have GVim v. 7.3, Exuberant CTags 5.8, omnicppcomplete (0.41) - all latest, to be exact.
I'm trying to generate tags to use in VIM, but it seems to totally ignore data in tags file.
I've used ctags to generate tags file for bada framework - the file seems to be okay, class definitions present etc. I also tried to apply the same command to STL from Visual Studio.
ctags -R --c++-kinds=+p --fields=+iaS --extra=+q --language -force=C++ "c:\bada\1.0.0\Include\"
Also, I've mapped generating tags via hotkey.
map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .
Trying to use any of files generated by these commands did not succeed.
The command :tags shows empty tag list, but doesn't give any error, and I have no clue how to fix this.
Yes, seems that vim actually handles spaces in a weird way (Windows only?), however there are workarounds: either use dos 8.3 short names or use a wildcard instead of a space (?), like
set tags=c:\program?files?(x86)\vim\tags
PS: which tag files was successfully loaded could be checked with the
:echo tagfiles()
command
The problem was with path to tags file: c:\Program Files\Vim\bada. The VIM didn't want to parse string with spaces no matter what the slashes/backslashes used.
Reinstalling VIM to c:\VIM solved the problem.