Dear all
are there any thoughts to create a plugin or tool that automatically generates article covers from PDFs (in the sense of thumbnails)?
Using the systematic paths to each PDF, let’s use php-gd to either once iterating through all published PDFs to create a thumbnail of the first page of each PDF and store the info to the db.
Or generate a jpg on the fly into the cache - meaning more server load but less iteration.
Or what about a #bash script for the /tools to be run on demand for back issues?
Thanks for your post. My search of the forum and Github issues seems to suggest that such a feature has not been explored. If you’re not familiar with it, you may wish to check in our plugin development guide: Plugin Guide for OJS and OMP
Having the ability to include an article cover manually has generally been the approach taken in OJS as it gives editors/journal managers more control. Others may also wish to weigh in on the feasibility of developing such a feature/plugin.
For issue covers we recently introduced the “generative cover”. Initially, on the issue/view page a p5js.org script generates a cover for the issue with all needed data (preferrably done in my sandbox on localhost). Colorsets are generated from colormind.io . For each issue 50 different SVG covers will be downloaded and used, especially for the archive view. Pitfall: I couldn’t get more than one of the same <script>...</script> to run on a single page. What happens now is that the template uses a random cover from one of the 50 for each issue - semi-generatively: Themenhefte | MedienPädagogik: Zeitschrift für Theorie und Praxis der Medienbildung (refresh the page to see the effect).
Currently two different designs are being tested and feedback is welcome. Designs are being switched from time to time (waves vs. mountains).
Thanks @klausru, those look really great. I think there would be a lot of interest in a plugin that could render a cover image based on the title of the article / issue. Especially if it could be fairly easily configured with the journal logo.
Dear @NateWr , dear all
based on your encouragements I’ve started to put elements together. It’s not yet a plugin, but still a hack within the theme. It already shows opportunities, difficulties and nice to haves:
The cover.tpl basically is an inline SVG that combines the following elements (medienpaed_hs/cover.tpl at main · klausru/medienpaed_hs · GitHub)
** some nice background, e.g.: {include file="images/waves_clean.svg"} ← preferrably SVG
** text elements to be filled from the database that can either be placed flat as <text> or complex as <foreignObject>
** the journal’s cover as <image x="179" y="236" width="400" href="{$publicFilesDir}/{$displayPageHeaderLogo.uploadName|escape:"url"}">
** and in my case, some additional <script>: generative colors for the waves in the background, but that’s really optional
Building an inline SVG is very easy. You could even put endless inline SVGs within an SVG
inline SVGs can be easily styled by CSS
<img> and <svg> placements behave differently: while <img> is easy to use, you can only manipulate its content via CSS with filter: .... The style of <svg> is fully able to be manipulated
it could be shown, that the three basic elements logo, background and text elements are either already variables in the system or could be stored as such (in case of background)
a form for the settings in the dashboard would be nice, but usually is only needed once for the setup
the greatest challenge: all elements within the cover.tpl-SVG need placements by x="..." and y="...". The cover.tpl-SVG itself only needs a viewBox="..." in pixel values; the rest is maintained by bootstrap and does the responsivity.
thus a form for the settings would need:
** an upload field for the background file or decorative styling
** some, at least, basic WYSIWYG (visual) styler to set the values for placing the elements
I haven’t found out yet, how to manipulate a template with a plugin
the rendered image quality of the smaller SVGs is not entirely convicing. Therefore check the mobile view, too.
This is really cool. I love that you’re doing this all with SVG, instead of trying to generate and render a raster image on the server. That opens up a lot of possibilities for adopting a technique like this into the core application, or a default theme, because colors could adapt to the journal’s theme’s colors.
This can be tricky because you effectively need to parse the template string, split it at the point you want, and insert your own content. It is usually easier to simply override the whole template file.