Oxygen & Author componenet: not the same rendering

[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

[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

[sebastienlavandier]

Hi Radu,

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

Sébastien.L

[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

[sebastienlavandier]

Hi Radu,

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

thanks in advance.
Sébastien.L

[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

[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

[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

[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

[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

[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

[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

[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