Problem styling HTML Galley OJS 3.0

Hi @Vitaliy,

I’ll see if @NateWr can have a look at the header problem – I suspect this will be a relatively quick fix. If it’s possible to leave the iframe approach in place for a little while, that would give him a chance to look.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @Vitaliy and @asmecher,

I posted a CSS which fixes the disappearing header in this thread – see here:

@Vitaliy: Can you please clarify »downloading external css and js seems to disappear«? I haven’t understood this one.

Tobias

Hi @twa,

Position fixed must be accompanied by !important in this case and this fixes problem only partially. Inner HTML moves up in this a little, but the header stays fixed.

As for css and js - some time ago I tried to use external refs to css and js files and them was blocked by iframe. But now all works fine. Don`t now what it was exactly, ifame problem or my mistake.

It also should be noted that iframe content is poorly indexed by search engines: https://support.google.com/webmasters/answer/34445?hl=en

Hi @Vitaliy,

Most of our users are generating HTML by exporting directly from word processors, which provides very little control over the HTML that results. If we don’t use an iframe approach, then OJS would need to either merge its own markup into the resulting HTML (difficult and probably ineffective), or leave the markup entirely to the 3rd-party generator, foregoing the chance to add the top navigation bar. Of those options the iframe is currently the lesser evil, I think.

Because the HTML article plugin is a plugin, we may be able to offer other tools to users who have more control over HTML generation – a rich text editor, for example. Is there an approach that you would prefer?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Our approach for publishing consist of 2 steps:

  1. First we transform doc or docx into JATS XML with Open Typesetting Stack and manually add some of data. Result is published with Lens Viewer

  2. Than JATS XML is transformed by XSLT into HTML. For now I am designing new style for result html with use of bootstrap and jquery. I can say that it is really good looking and adaptive. Most markup is generated automatically by javascript so this not requires any time. I will share the design once it will be finished.

I am planning also to inject into display.tpl (in the plugin directory) the code for our journal header and footer. Do not know for now how it is complicated but simple codes for lens viewer I already wrote. I think it will be ideal variant.

Hi @Vitaliy,

Do you think an XSL-based XML to HTML plugin would be useful? This would presumably transform the XML to HTML server-side and serve it to the end user’s browser as HTML. We used to have something similar in OJS 2.x but it wasn’t particularly refined.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Such plugin, if it will transform to HTML on server side, certainly would be useful for XML-oriented journals. But I don`t now how many journals which use or are planning to use OJS3 are adopted the use of xml as intermediate format.

Hi @Vitaliy,

That’s a usage that we’re actively trying to facilitate, and I suspect (hope) journals are increasingly going to be working with JATS XML even if they don’t use OTS.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @asmecher,

I’d prefer the XML approach too, but sadly enough, most authors are still clinging to MS Word. Since we are using Word to InDesign to PDF, I’m still loking for a good way to get to JATS XML from InDesign.

Back to topic:
If OJS would generate HTML galleys out of the XML automatically with the opportunity to inject user defined CSS and JS and add the metadata automatically, that would definitly be the best solution!

Tobias

Hi @twa,

Have a look at Open Typesetting Stack – that’s what @Vitaliy is using. We’ll be starting external testing and firming up “release” plans sometime soon. I’ve heard that InDesign generates some pretty funky PDF that might be hard to use as a basis for conversion into something else, but perhaps if you try a PDF generated by Word directly, you’ll have better luck.

Regards,
Alec Smecher
Public Knowledge Project Team

Greetings @ctgraham,

I am planning to do some testing on the site on this weekend and will deactivate iframe. Please let me now if you have seen the problem or when you be able to do it.

@Vitaliy, I think you meant to tag @asmecher here, no?

Sorry. Actually @asmecher was pointing on @NateWr

@Vitaliy I’m sorry but I actually don’t really understand the problem you’d like me to take a look at. Can you give some step-by-step instructions on how to reproduce it. Include details about what you expect to happen and what happens instead?

@NateWr,

I have already disabled iframe. If html contains internal links like navigational intra-article menu (a href=#someid), clicking on that links causes all inner html in iframe to move up. That, in turn, pushes iframe menu above the visible screen.

I got that and had a deeper look into the htmlGalley-Plugin. As far as i can see the display.tpl and display.css are resposible for creating the HTML-galley view. I also looked at the static pages plugin and found how the static page is embedded into the journal page.

I added these two lines to the display.tpl of the html galley plugin:

{include file=“frontend/components/header.tpl”}

{include file=“frontend/components/footer.tpl”}

This really works fine and you have all the navigation elements, the sidebar and footer around the html-article.

I also have noticed that an iframe is used for including the html galley. For longer texts we get a not-so-nice-looking vertical scrollbar in the iframe. How can this scrollbar be avoided? Including scrolling=“no” on the iframe worked but the most of the article gets cut off.

Or how is it possible to circumvent the iframe?

Hi @florianruckelshausen,

What specific version of OJS are you using? I believe we put a tweak on scrolling behavior into the 3.0.2 release.

Regards,
Alec Smecher
Public Knowledge Project Team

Its 3.0.1 but but i upgraded to 3.0.2 and no changes so far. A colleague recommended to embed the html using

<?php
echo file_get_contents("...");
?>

instead of the iframe. But it seems that the php-code isn’t parsed when opening the article on the OJS site. I tried adding

AddType application/x-httpd-php .tpl

to the .htaccess file but no effect so far.

Hi @florianruckelshausen,

PHP code and AddType directives won’t work because OJS takes care of serving the article contents, not Apache. Is your site public? If so, can you post an example URL?

Regards,
Alec Smecher
Public Knowledge Project Team