Page 1 of 1

Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 10:12 am
by sebastienlavandier
Hi,

I don't find why but I didn't have same rendering in author view, when I use the same framework package between Oxygen 16.1 and Author component 16.1.
Empty nodes seems to be diplayed in block and not.
It's not a CSS issue because the same CSS files are used.

First I had reset global options on Oxygen 16.1, to be sure is not an options.
Result: Rendering seems to be "compact" and empty node are displaying inline.

With the Author component and an empty options.xml (so without external options), rendering seems to not be "compact" and some empty nodes are displaying in block.

Do you have an idea for this particular case ?
Thank in advance for your help.

Sébastien.L

Re: Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 10:37 am
by Radu
Hi Sébastien,

I'm not sure, have you used ro.sync.ecss.extensions.api.component.AuthorComponentFactory.setObjectProperty(String, Object) in the Java applet code so forcefully set certain options?

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 11:16 am
by sebastienlavandier
Hi Radu,

No, since Oxygen 14.2 we used an options.xml to change some options in our application.

Sébastien.L

Re: Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 11:29 am
by Radu
Hi Sébastien,

Could you possibly send some screenshots to support@oxygenxml.com?
Maybe if I fully understand the difference in rendering I could give you more hints.

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 11:43 am
by sebastienlavandier
Hi Radu,

How should be the options.xml file format ?
Could you send me an exemple ?

thanks in advance.
Sébastien.L

Re: Oxygen & Author componenet: not the same rendering

Posted: Tue Jun 09, 2015 12:04 pm
by Radu
Hi Sébastien,

The options.xml should be generated by exporting options from a standalone Oxygen installation:

http://www.oxygenxml.com/doc/ug-oxygen/ ... tions.html

It's format is something like:

Code: Select all

<serialized version="15.2" xml:space="preserve">
<map>
<entry>
<String>key_name1</String>
...........
</entry>
...............
</serialized>
so you can also edit it and filter out entries which you do not want to be imposed.
We do not have an API reference which would list all possible keys and all possible values.

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Wed Jul 01, 2015 11:17 am
by Vince
Hi,

I update this post with a progress status of our analysis (Sébastien and I are collaborating on same standalone Author Component application).

We use the sample standalone Author Component application contained in the module named oxygen-sample-applet in oXygen SDK project v 17.0.2.
In this sample integration, we changed the default frameworks by our.
At this stage, rendering is good because empty node are displaying inline.

Then, by adding the same dependencies that our application, we reached the bad rendering (empty nodes are displaying in block)

And by gradually removing dependencies, we identify that the jar org.slf4j:slf4j-api:1.7.12 is the origin of the difference in the rendering process .

How can we explain this ?

Thank you for your answers.

Regards,
Vince

Re: Oxygen & Author componenet: not the same rendering

Posted: Wed Jul 01, 2015 1:27 pm
by Radu
Hi Vince,

I have no idea why that JAR library would influence things. I do not know anything about it, we never used it internally for anything.

Are you absolutely sure that particular JAR library is the cause? So if you comment a dependency to it, the component no longer has problems? Do you need that JAR library for anything?

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Fri Jul 03, 2015 12:58 pm
by Vince
Hi,

You are right, I made a mistake, this jar isn't the cause. In fact, our framework need this jar. If we don't include it in dependencies, Oxygen say us that a class (StylesFilter implementation) can't be loaded by the classloader.

Now, I can see that :
- not using a cssStylesFilterExtension, no problem, empty nodes are displaying inline
- using a cssStylesFilterExtension (code below), rendering changes, empty nodes are displaying in block

Code: Select all

public class MyStylesFilter implements StylesFilter {

@Override
public Styles filter(Styles styles, AuthorNode authorNode) {
return styles;
}

@Override
public String getDescription() {
return null;
}
}
When I take a look at ro.sync.ecss.css.Styles class, I see that there is a notion of KEY_IMPOSED_DISPLAY. What is it ?


Regards,
Vince

Re: Oxygen & Author componenet: not the same rendering

Posted: Fri Jul 03, 2015 2:12 pm
by Radu
Hi Vince,

What version of the Author Component are you testing this with?
If the method does not change the styles in any way, could you try as an experiment to return null instead of the same styles object?

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Fri Jul 03, 2015 3:45 pm
by Vince
Hi,

I'm testing with the last version 17.0.2.

And return null instead of the same styles object solve my problem indeed.

Our framework was written onto version 14.2 and this rendering problem does not previously occur with the same StylesFilter.

Vince

Re: Oxygen & Author componenet: not the same rendering

Posted: Fri Jul 03, 2015 5:02 pm
by Radu
Hi Vince,

I will investigate this problem.

In the meantime you can return null if no modifications are made to the object, the workaround is also backward compatible.

Regards,
Radu

Re: Oxygen & Author componenet: not the same rendering

Posted: Mon Jul 06, 2015 10:05 am
by Radu
Hi Vince,

Sorry but I cannot reproduce this issue on my side.
I added a styles filter which returns the same unmodified styles and used that when looking at various XML + CSS samples I had (DITA, Docbook documents) but could not find any rendering problem.

So if at some point you have some time to prepare an XML + CSS sample I could use to reproduce the issue on our side, that would be great. Otherwise I do not know what I could do without reproducing the issue on my side.

Regards,
Radu