I am quite new to inkscape and I would like to process a batch of SVGs using the command line interface with the following command (in the same directory as the SVG):
$ inkscape -D -z NMY.svg
However, when I try to load an SVG with the CLI I get the following warning:
** (inkscape-bin:8875): WARNING **: Can't open file: NMY.svg (doesn't exist)
** (inkscape-bin:8875): WARNING **: Can't open file: NMY.svg (doesn't exist)
** (inkscape-bin:8875): WARNING **: Specified document NMY.svg cannot be opened (does not exist or not a valid SVG file)
However, opening the same SVG from the GUI properly displays the image.
Here is the header SVG in question in case there is something wrong with it:
<?xml version='1.0' encoding='iso-8859-1'?>
<svg version='1.1' baseProfile='full'
xmlns:svg='http://www.w3.org/2000/svg'
xmlns:rdkit='http://www.rdkit.org/xml'
xmlns:xlink='http://www.w3.org/1999/xlink'
xml:space='preserve'
width='250px' height='150px' >
I am using inkscape Inkscape 0.92.2 5c3e80d, 2017-08-06 on MacOS 10.14.
Thanks!
Found the problem, I had to specify the absolute path to the file.
Related
When developing an application based on GTK4, a log will be printed every time it is started. How can I get rid of it?
(conquerdocker:17460): Gtk-WARNING **: 09:13:21.962: Unknown key gtk-button-images in /home/aszswaz/.config/gtk-4.0/settings.ini
(conquerdocker:17460): Gtk-WARNING **: 09:13:21.962: Unknown key gtk-menu-images in /home/aszswaz/.config/gtk-4.0/settings.ini
(conquerdocker:17460): Gtk-WARNING **: 09:13:21.963: Unknown key gtk-toolbar-style in /home/aszswaz/.config/gtk-4.0/settings.ini
If you are not concerned about having any log output when you are executing your program, you could call your program and redirect the logging output to "/dev/null", such as:
./your_program_name > /dev/null
Alternatively, since your program is most likely a GUI program and doesn't require a terminal/console window, you could set up a desktop file similar to the following example.
[Desktop Entry]
Type=Application
Name=GtkProgramName
Icon=/home/username/.local/share/icons/hicolor/48x48/apps/GTK.png
Categories=Utilities;
StartupNotify=true
Terminal=false
Exec=/path/to/your/Programs/your_program_name
The key attribute here is the "Terminal=false" attribute which will run your program without a terminal, and therefore a user would not see spurious messages. Desktop files usually are placed in the "~/.local/share/applications folder" and have a permission mask of "rw-rw-r--".
You might give those options a try.
Regards.
MAFF files are simply zip files. I'm trying to create a handler for .maff in linux so that when I click on them or type xdg-open x.maff it will call my handler instead of the default which is to open the directory in nautilus. I created an application-x-maff.xml file that contains:
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="application/x-maff">
<comment>maff type</comment>
<magic priority="100">
<match offset="0" type="string" value="PK\x03\x04" />
</magic>
<glob pattern="*.maff"/>
</mime-type>
</mime-info>
and saved in ~/.local/share/mime/packages. Created also a ~/.local/share/applications/maffapplication.desktop that contains
[Desktop Entry]
Type=Application
MimeType=application/x-maff
Name=Maff Handler
Exec=<my home path>/bin/linux/maffHandler
and executed
% update-mime-database ~/.local/share/mime/packages/
% update-desktop-database ~/.local/share/applications
If I do
% gio info x.maff (filtered)
standard::content-type: application/x-maff
standard::fast-content-type: application/x-maff
and if I do
% gio mime application/x-maff
Registered applications:
maffapplication.desktop
Recommended applications:
maffapplication.desktop
everything seems to be right ... but then xdg-open x.maff does not work, still calls nautilus ... worse yet, if I do
% xdg-mime query filetype x.maff
application/zip
I'm sure I'm missing something ... somehow I need to override this association between the .maff file that starts with the same magic as a zip file to no avail ... I tried all kinds of modifications on the xml file, with and without the magic, nothing works
By the way, if I do
% maffHandler x.maff
it works perfectly and opens the maff file in firefox, I'm willing to share the C++ code of that if anyone is interested
Seems that TDE (Trinity Desktop) does not properly set two important environment variables
setenv XDG_CURRENT_DESKTOP KDE
setenv KDE_SESSION_VERSION 5
Once they are set at .login (unfortunately had to log out and login again) xdg- scripts started working properly and recognizing the MIME types. The other problem is that TDE requires that you manually add the association on Control Center -> TDE Components -> File Associations.
After environment variables properly set for my environment and File Associations set, then it all works perfectly. Thanks
I have a SVG image on this path http://www.quickdesign.com/user-uploads/5555f546857ce-saved.svg
Which i need to convert into PNG for which i am using below code on this php file http://www.quickdesign.com/png.php
<?php
$svg_file_name = 'user-uploads/5555f546857ce-saved.svg';
$png_file_name = 'png/converted.png';
$im = new Imagick();
$im->setBackgroundColor(new ImagickPixel('transparent'));
$svg = file_get_contents($svg_file_name);
$svg = '<?xml version="1.0" encoding="UTF-8" standalone="no"?>'.$svg;
$im->readImageBlob($svg);
/*png settings*/
$im->setImageFormat("png32");
$im->writeImage($png_file_name);
header('Content-type: image/png');
echo $im;
$im->clear();
$im->destroy();
?>
If i remove the line $svg = '<?xml version="1.0" encoding="UTF-8" standalone="no"?>'.$svg; Then it gives fatal error Uncaught exception 'ImagickException' with message 'no decode delegate for this image format
Can anyone please help me how to convert above svg image to PNG image using PHP.
Any help would be appreciated.
Thanks
ImageMagick uses delegates to read some images. It looks like the delegate it is using for SVG files on your system is unable to the SVG file you are telling it to read.
Reading that file also fails on my system due to this bit:
<stop fill="url(#svg_14)" stop-color="#A0D9F7" offset="0"/>
with the error message:
php: unrecognized color `svg_14' # warning/color.c/GetColorCompliance/1046.
php: unable to open image `svg_14': No such file or directory # error/blob.c/OpenBlob/2674.
php: no decode delegate for this image format `' # error/constitute.c/ReadImage/501.
url support inside SVG files is a bit flaky. It seems that svg_14 is defined at the end of the file. Moving it to the start makes the file be 'readable' but the image looks different to how it should appear.
I would suggest finding out what delegate ImageMagick is using to decode SVG files, which may be found with convert -list configure and finding if there is a more recent version of that library which fixes the issue.
I configured the update url as following:
"update_url": "https://www.myextension.host.com/updates.xml"
And the updates.xml file:
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='aplfhldgnogkgfjopdbppahookjpfpad'>
<updatecheck codebase='https://www.myextension.host.com/updateExtension/chrome_2.0.crx' version='2.0' />
</app>
</gupdate>
But when I installed the extension and click the update now, nothing happened, the server does not detect the request for the updates.xml file either.
I started chrome with
chrome.exe --enable-logging --log-level=2
but cannot find any error log about the update. Well I did see some logs but I'm not sure it's related or not. Post below too:
[5468:1956:0515/114000:ERROR:accelerated_surface_win.cc(208)] Reseting D3D device
[5468:188:0515/114003:ERROR:textfield.h(156)] NOT IMPLEMENTED
[5468:428:0515/114007:ERROR:accelerated_surface_win.cc(208)] Reseting D3D device
[4500:476:0515/114131:ERROR:ipc_channel_win.cc(132)] pipe error: 109
[5468:3560:0515/114131:ERROR:accelerated_surface_win.cc(208)] Reseting D3D device
[5468:3048:0515/114218:ERROR:accelerated_surface_win.cc(208)] Reseting D3D device
[5676:1276:0515/120110:ERROR:ipc_channel_win.cc(132)] pipe error: 109
[3596:6072:0515/120540:ERROR:ipc_channel_win.cc(132)] pipe error: 109
Is there any debug way to better debug the update operation?
To get debugging information about the extension's updater process, start Chrome / Chromium with the following command:
chrome.exe --vmodule=extension_updater=2 --enable-logging
After starting Chrome, a log file called chrome_debug.log will be created in your user profile directory.
Without any other information, I guess that you've either got a typo in the extension ID or in the update URL. If your extension still doesn't install after fixing this issue, check whether the crx file is served with the application/x-chrome-extension MIME-type.
I'm trying to register a custom file type as a mime-type in linux. My custom filetype, with a custom extension, is actually a zip archive containing various xml and other files.
The problem I'm having is that my operating system (kubuntu) won't recognize the file as my custom mime-type but insists on it being a zip file.
I'm not sure where I should start trying to fix my problem. I've used the following mime info file (tugraz-caleydo.sharedmimeinfo):
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
<mime-type type="application/x-cal">
<comment>Caleydo Project</comment>
<glob pattern="*.cal"/>
</mime-type>
</mime-info>
My Desktop Entry (caleydo.desktop, correctly registered in /usr/share/applications):
[Desktop Entry]
Version=2.01
Encoding=UTF-8
Name=Caleydo
GenericName=Data Visualization
Comment=Visualization for Molecular Biology
Exec=/usr/bin/caleydo
Icon=/usr/share/pixmaps/caleydo_256.png
StartupNotify=true
Type=Application
Categories=Science;
MimeType=application/x-cal;
And these are the commands I'm trying to use:
sudo xdg-mime install --mode system tugraz-caleydo.sharedmimeinfo
sudo xdg-mime default caleydo.desktop application/x-cal
sudo update-mime-database /usr/share/mime
However, this still gives me:
$ xdg-mime query filetype export_2012.cal
application/zip
I finally found the issue:
the mime info file has to have exactly the name of the mime type. Renaming it to x-cal.xml did the trick.