Is there a list of supported image formats? It seems that Fiduswriter does not accept pdf-images, for example. What about other vector-formats?
Nils
Hey,
you should be able to use all images that you can also use on the web that are provided by common browsers like jpg, gif, png. As for vector formats, there is SVG. PDF is not normally referred to as an image format, I don’t think, but if your PDF does contain vector images you should be able to convert it to an SVG.
Thanks for the clarification. For printing, PDF is a very common format, much better and more reliable than SVG. EPS or AI would be viable alternatives, but either PDF, EPS or AI is a must-have for a preprint-tool like FidusWriter, at least if envisioned as tandem for OJS (as I do at the moment).
Hey @nms, just in relation to the “must-have”: there are many different ways people use Fidus Writer. This is the first time in the past 8 years of development that hear from someone who wants to include PDF files as input images (or EPS/AI). It probably also depends a bit on the subject. I am saying that not because I am against adding such a feature, but because there have been quite a few people asking for some very subject specific feature, not realizing that not everyone needs exactly that one thing.
PDF as an output format is of course supported.
It should be possible to add such a feature though. If this is something you or your institution is interested in contributing with, I’ll be happy to point you to where in the source code you could add that.
@nms Btw would you have an example article where the images are inserted as PDF/EPS vector images? Just so that I understand what it is you can do that you could not do with an SVG file?
Sorry, yes, I can imagine that different people demand all different kind of things.
I am thinking in a way of workflow where FidusWriter could play a part together with OJS for journal publishing, using the mutual plugins for review and revisioning. It would kind of break this workflow if you have to supply high quality images via a second pipeline.
SVG is not standardized and it can be virtually impossible to produce printable images from SVG-files, especially if they contain a complex mix of vector and raster information. With SVG your cannot be sure that the printed result will be the same as you see on the screen. If you look at, for example, the “Journal of Neolithic Archaeology” (https://www.jna.uni-kiel.de/index.php/jna/), the vector images in all the articles there were PDF-, EPS- or AI-files.
Ok, thanks, I think I found an example of a vector image on page 15 of this article: http://www.jna.uni-kiel.de/index.php/jna/article/view/196/335
I found another one on page 52 of http://www.jna.uni-kiel.de/index.php/jna/article/view/186/318 . This second one seems to connect raster and vector graphics.
I then converted both to SVG, imported them into a new document and created a PDF from that document. As far as I can tell, they came out the same way they went in. Also the raster information was preserved.
An SVG test article - Fidus Writer.pdf (3.8 MB)
Maybe there has been some improvement in SVG since last time this was tested? Or maybe I did not pick the right images? I didn’t find any vector images in the 2020 issue.
At any rate, it would be possible to add support for AI and PDF images if this is something your institution would like to sponsor, but for displaying in the editor and for some of the output formats (like HTML and EPUB), one would have to convert the files to SVG because that is the format that is supported on the web.
I think a lot of people in the W3C would probably see it the other way round - SVG is a standard, whereas AI is a proprietary format of a single company. PDF used to be that but has since become a standard.
It probably depends on the field, but “pre-print” in many subject doesn’t actually mean that it is ever going to be printed (or only in a very limited amount). Articles just live on the web for direct consumption there.
Thanks for your time in testing! However, I recently had to deal with SVG-images coming from Inkscape. Our graphic department spend hours on fixing the line width and replacing the text which had been converted to shapes. Support for AI/PDF would be great, but how would you go about implementing it in the editor (and possibly transferring it to OJS) and at the same time displaying converted SVG-images?
While I agree that web-publishing will steadily increase in importance, at least in my field of study printing of books and journals is still widely done. The Journal of Neolithic Archaeology appears as PDF on the web and in print. For that, images need to meet minimal requirements, especially in terms of resolution.
If you consider FidusWriter as collaboration tool for academic writing, I think it should (IMHO) cater for the possibility to submit text, images and tables separately (and ideally automatically). While it is clear that this is not feasible for commercial solutions like EditorialManager used by the big publishing companies, it might be possible with OJS, considering the alreay existing APIs.
I do not have a FidusWriter-instance at my disposal, unfortunately, to thoroughly test the setup I have in mind.
Hey,
I also used Inkscape for the conversion from PDF to SVG.
I also converted the text to shapes, because that is the only way to ensure that it looks the same in all browsers, no matter what fonts are available locally. What would the advantage be of keeping it as a text? Especially if you are going to print it?
I don’t think there is any issue here. You assign an id to each image (as is done already) and you then assign different formats to each id. So for example one image is image “215”. We store a PNG thumbnail of that image to show some places in the menus. We store an SVG version to display in the editor and embed in any of the output formats that require SVG. And we would store an EPS Version that could be included in those export formats that support it (LaTeX, maybe JATS).
Books are being produced with Fidus Writer, also for print (see for example https://akademie-oeffentliches-gesundheitswesen.github.io/krisenmanagment/ ). But so far none of those who do and who are sponsoring Fidus Writer development have asked for EPS/PDF/AI support.
The economics of Fidus Writer, being an open source project, basically work this way: If you want a feature, especially one that is very specific for your field, then you can either hire us to program that or you can apply for some funding yourself and have some programmers on your end do it and we help with integrating it into the main codebase. I see you are working with some DFG funding. That could for example be a place where you could apply for funding to make this happen.
I don’t think I fully understand what you are proposing. When submitting or sending files to other systems, depending on the receiving system, it already submits each file individually. For example, the github exporter that is currently being developed submits each image that is contained in the exported document as a separate file.
Inkscape does not know CMYK, only with workarounds. This is a serious short-coming.
You have to be able to change the font in order to ensure one fairly similar look for all papers.
I did not realize that! This indeed sounds like a very reasonable and solid solution.
Again, this sounds exiting and exactly as I wished for. I have to rely on the Rechenzentrum to set up a working FidusWriter-instance to test such things. Unfortunately, at Corona-times they are very busy in enabling the digital university …
OK, I see. Could this problem be generalized? Maybe another journal wants the original excel file with the numbers for graphs so that all the graphs look the same. A solution then could be to add the option of adding “source files” to any document so that the editors have access to those files. The instructions for the journal could then include wording like “Please add the original EPS/AI/PDF file for graphs and images in the source files section.” In the article itself the author can upload an SVG or PNG of the file to be used while editing the document, and the person doing the final layout still has access to everything else.