I have put the jar file inside the library of my magnolia(https://nexus.magnolia-cms.com/#nexus-search;classname~ImagingServlet), but when I invoke the url to return the cropped image, I get an error, if someone can help me.
[this is what appears to me1
I would guess that you are either missing the destinations folder or user has no access to it. Alternatively you are missing imaging support for DAM - see more at various additional jars you might need in documentation.
Also it seems you just copied thumbnail link from the admincentral, so perhaps you might want to read more on using themes and predefined image variations.
Related
I am trying to find the file path of nested links and ran into a problem.
I am interested in the 2nd level, meaning finding the file path of a link inside one of the links in the file that I currently have opened.
My problem is where the reference Type is Overlay, if reference type is Attachment I don't have a problem.
I am also assuming the files are in BIM360 cloud, but I believe I have the same problem if the files were local.
I am able to get the RevitLinkInstance and RevitLinkType object for those links.
However, if I try to use GetLinkDocument() on the RevitLinkInstance I get null, and trying getting the InSessionPath using GetExternalResourceReferences() on the RevitLinkType get me "Autodesk Docs://" and stops there without the real path.
Will appreciate any help including letting me know if this is at all possible.
Thank you,
To my knowlegde it is impossible to get the link within a link through one Document. This is because with Overlay the link is not stored into the Link. That is also why it works with Attachment. Because Revit than makes it a point to store the Link in that file and thus it is part of that Revit file.
What you could do instead is search for the file path of the first link. Then use the file path in the OpenAndActivateDocument(string filepath) method. Repeat the first step to get all RevitLinkInstances of this Document. You can get the needed information from this link, store it in a variable and close the link document.
If an example is needed please let me know.
I've run into an issue where there are a collection of .dds(direct draw surface) files which I need to be able to display within an electron/react app. From what I know, a .dds file must be converted to a png/jpeg before being able to be rendered in an img tag. This must also be done completely in memory as I don't want to create additional files.
Here is what I've tried.
Preview-DDS: https://github.com/Jam3/preview-dds
DDS-Parser: https://github.com/Jam3/parse-dds
I noticed Preview-DDS has an option to convert .dds to .png yet I had no luck replicating it in memory. This isn't a subject im really knowledgable on so I'm hoping someone can get me pointed in the right direction!
Stuck in this weird situation at work. I have .doc files I'm parsing with Node.JS. They have photos in them that are .emf I want to display in my web app. I have no issue getting the emf file out of the word doc, but I can't figure out how to display it on a webpage. Simply embedding as is didn't work. I tried to find a utility to convert them automatically but with no luck. I thought of converting them myself but can't find any tecnhical info on the .emf file.
Any suggestions?
EMF (WMF) are the SVG like formats of the 1990's.
I can't give you the full solution in this space but checkout this thread that uses Apache Batik
If you don't want to build it yourself perhaps try the paid version of converters
If you can't afford I would recommend to host the Batik and make a service endpoint and make calls to generate the desired format from EMF. It may turn out actually faster.
I'm using the Node.js version of TiddlyWiki, and I'd like to link to images on my filesystem.
The documentation listed here doesn't work; in the [img[path]] tag, for the path part I put something like /Users/documents/ken/path_to_image.jpg yet nothing shows up in the tiddler.
My wiki exists in /Users/documents/ken/wiki.
I know this is an old post, but zacts stated that you can use a macro plugin or simply use the [img] tag to point to the relative path of the image from the tiddlywiki.html file, but the op is using the node.js version, and zacts apparently didn't read that. There is no tiddlywiki.html file for TiddlyWiki on node.js. That only works with the static .html version of tiddlywiki, not the node.js version.
Currently there is no way to point to a local file through the node.js version of Tiddlywiki as node.js is not a webserver, therefore it does not see subfolders like /images/ off of the root url. The only way is to run a parallel web server on the same machine and use the full web url to the images served up from the web server.
In case someone else stumbles across this problem:
I could not find this documented anywhere, but what seems to work is to just copy the image in the tiddlers directory, then restart the nodejs server, and search for the image title from tiddlywiki. There will be a tiddler that contains that image, that you can edit at your leisure.
Alternatively, copy the image as image_name.png (or image_name.jpg) into the tiddlers directory, and create a image_name.png.meta text file with the following contents:
title: image_name
type: image/jpeg
Upon restart of the tiddlywiki nodejs server, a tiddler with title image_name which contains the image will be there.
If you are using the Node.js version, you can simply put it in the ./files folder, and then use [img[. /files/xxx.jpg]] to reference it.
I had this same issue recently, and I found a neat little solution for it. Let me send you the links, and I'll post the snippets here.
I happened to stumble across this tiddlywiki image gallery homepage that linked to a macro plugin that lets you link in local images. Here is the link to the tiddler for the plugin: http://www.richshumaker.com/tw5/tw-photo.html#External%20Image%20Path. Here is the original TiddlyWiki google groups post of the plugin for this: https://groups.google.com/forum/#!msg/tiddlywiki/ChRV6sjQpn4/bCm35_XhGmkJ.
I hope this helps! =) (note: when I get more time I may clean up the formatting of this post).
It is very simple, you use _canonical_uri field
_canonical_uri field
The field value is something like "./wiki/path_to_image.jpg" (mine is "./files") in the same level as the tiddlers folder. I did not experimented with files outside the root folder of the wiki. The dot in the path might be ommited.
The content type might be "audio/mp3" "image/jpg" look at the "parser" shadow tiddlers. Your Browser might support more content types like "audio/wav" but you would have to add this line to "$:/core/modules/parsers/audioparser.js" For example. Might be the same thing for images. Check your browser support.
I really do not know why this fact is so obscure, but it work wonders.
Imagine an environment in which users can upload images to a website by either uploading it from their pc or referring to a remote url.
As part of some security checks I'd like to make sure that the referenced object is indeed an image.
In the case of a remote-url, I of course check the content-type, but this isn't bullet-proof.
I figured I could use ImageMagick to do the task. Perhaps executing the ImageMagick.identify() method and if no error is returned and returned type is either JPG|GIF|,etc. the content is an image. (In a quick check I noticed that TXT files are identified correctly as well, so I have to blacklist these)
Is there any better way in doing this?
You could probably simply load the image via ImageMagick's appropriate function for your language of choice. If the image isn't formatted properly (in terms of internal formatting, not its aesthetic properties, that is), I would expect ImageMagick to refuse to load it and report an error. In PHP, for example, readImage returns false if the image fails to load.
Alternatively, you could read the first few hundred bytes of the file and determine if the expected image file format headers are present; e.g., "GIF89" etc.
These checks may backfire, if your image is in a compressable format (PNG, GIF) and it is constructed in a way similar to a zip bomb https://en.wikipedia.org/wiki/Zip_bomb
Some examples at ftp://ftp.aerasec.de/pub/advisories/decompressionbombs/pictures/ (nothing special about that site, I just googled decompression bombs)
Another related issue is that formats like SVG are in fact XML and some image processing tools are prone to a variant of "billion laughs" attack https://en.wikipedia.org/wiki/Billion_laughs
You should not store the original file. The generally recommended approach is to always re-process the image and convert it to an entirely new file. There have been vulnerabilites exploited inside valid image files (see GIFAR), so checking for this would have been useless.
Never expose your visitors to an image file that you have not written out yourself and for which you did not choose the file name yourself.