Community
Participate
Working Groups
Created attachment 235521 [details] document type plugin, screenshots, bundle lists I've checked out new versions V1.1.0M1 and V1.1.0M2 with my previusly created document type plugin and sadly I found both can't handle my plugin's css as V1.0.0 did. I have check out if extension mechanisms have not changed so I've looked into org.eclipse.vex.docbook bundle to find out differences. I have not found any changes which can in my opinion makes some killer difference. Symptoms are: It renders for e.g. tables or headings but it stops rendering other blocks after one is rendered. So I get only heading or only table and rest of document is not rendered. I also encountered another problem with tables, since I can't place cursor inside the table starting M1. I have tried Juno and Kepler both fresh RPC bundle installations. Please find attachment sample plugin (consists only of metadata and css), screenshots and bundle list (Kepler RCP was used but problem is same in Juno) comparing V1 ans V1.1M1 or M2. No log entry has been created in this case.
The plug-in you attached does not contain the DTD file (the whole dtd folder is missing). Did you check the folder in the build.properties file in order to make it included in the bundle JAR file?
At a first glance, there seems to be a problem in org.eclipse.vex.core.internal.layout.AbstractBlockBox.findNextBlockNode(LayoutContext, IParent, int, int): With parent.children().in(new ContentRange(startOffset, endOffset)).withoutText() we start the search for the next block element in the Document node within the range [10, 685]. The result of this expression is empty. So this is definitely a regression which was introduce by the use of the children axis here.
(In reply to Florian Thienel from comment #1) > The plug-in you attached does not contain the DTD file (the whole dtd folder > is missing). Did you check the folder in the build.properties file in order > to make it included in the bundle JAR file? I have not included dtd since it should not be depended on it while rendering. I have created minimalistic sample plugin. Sample xml document doesn't contain DTD reference so it has to be selected in dialog. However it bahaves the same for me even with everything this included.
(In reply to Florian Thienel from comment #2) > At a first glance, there seems to be a problem in > org.eclipse.vex.core.internal.layout.AbstractBlockBox. > findNextBlockNode(LayoutContext, IParent, int, int): > > With parent.children().in(new ContentRange(startOffset, > endOffset)).withoutText() we start the search for the next block element in > the Document node within the range [10, 685]. The result of this expression > is empty. > > So this is definitely a regression which was introduce by the use of the > children axis here. It's only strange that internal docbook type plugin seems to render all with no problems. There must be some difference where it makes 1.1M1/M2 more strict than 1.0.
The fog lifted a little bit: it has nothing to do with tables. I found a workaround for your example: add "display: block;" to the stylesheet for the root element: SampleDoc { display: block; } A little bit of background: The root cause is, that we don't have a default stylesheet and are now a little more restrictive about which elements are beeing handled as "block" elements. If an element has not explicitly set "display: block;", then it is not handled as a "block" element. For rendering we first look for the "block" elements in the document. Because the root element is not a "block" element, we do not find any further "block" element after we have found the title.
(In reply to Florian Thienel from comment #5) > The fog lifted a little bit: it has nothing to do with tables. I found a > workaround for your example: add "display: block;" to the stylesheet for the > root element: > > SampleDoc { > display: block; > } > > A little bit of background: The root cause is, that we don't have a default > stylesheet and are now a little more restrictive about which elements are > beeing handled as "block" elements. If an element has not explicitly set > "display: block;", then it is not handled as a "block" element. For > rendering we first look for the "block" elements in the document. Because > the root element is not a "block" element, we do not find any further > "block" element after we have found the title. I can see. Also 'Sect' must be set as 'block'. 1) According this I have also discovered another rendering issue even for existing docbook type. If there is no explicit type provided (e.g. docbook root: <article xmlns="http://docbook.org/ns/docbook" version="5.0">) dialog appears to select the type in VEX and once you have document with tables, rows are rendered differently: cell-space-cell-space-cell. It's also the case of provided sample xml document. 2) Cursor still cannot be placed within the table cell even for internal document types.
> 2) Cursor still cannot be placed within the table cell even for internal > document types. I just committed a bugfix that should improve caret placement in tables (commit 51c7997df9883c8f38401c97ac8f93440de0328b).
Using the new mechanism to define default style in vex-core-styles.css, I added 'display: block' as default for all elements. This fixes the rendering issue. https://git.eclipse.org/r/#/c/16677/
> 2) Cursor still cannot be placed within the table cell even for internal > document types. I can reproduce this behavior. Currently VEX loads the Doctype you select in the dialog, but does not apply it completely. You'll also notice that the content assist does not work in this case. As a workaround, you can put the Doctype definition in your XML manually, till this is fixed.
(In reply to Carsten Hiesserich from comment #9) > > 2) Cursor still cannot be placed within the table cell even for internal > > document types. > > I can reproduce this behavior. Currently VEX loads the Doctype you select in > the dialog, but does not apply it completely. You'll also notice that the > content assist does not work in this case. > As a workaround, you can put the Doctype definition in your XML manually, > till this is fixed. I guess you mean 1st point not the 2nd. Doctype behaves the same in all versions in that manner that for undefined or defined documents by SystemID, document type has to be selected in dialog. DTD is then not resolved, only css for rendering. Once dtd is referenced by PublicID in document both dtd and css is resolved. But missing dtd shouldn't impact on rendering. Once both dtd,css are resolved table is rendered well but otherwise it creates additional blank cells (or blank space) in betwean each other. Is this you have already reproduced as well?
(In reply to Florian Thienel from comment #8) > Using the new mechanism to define default style in vex-core-styles.css, I > added 'display: block' as default for all elements. This fixes the rendering > issue. > > https://git.eclipse.org/r/#/c/16677/ OK. I think it's better. Oxygen for example uses the same default.
(In reply to Kantor Jan from comment #10) > (In reply to Carsten Hiesserich from comment #9) > > > 2) Cursor still cannot be placed within the table cell even for internal > > > document types. > > > > I can reproduce this behavior. Currently VEX loads the Doctype you select in > > the dialog, but does not apply it completely. You'll also notice that the > > content assist does not work in this case. > > As a workaround, you can put the Doctype definition in your XML manually, > > till this is fixed. > > I guess you mean 1st point not the 2nd. Doctype behaves the same in all > versions in that manner that for undefined or defined documents by SystemID, > document type has to be selected in dialog. DTD is then not resolved, only > css for rendering. Once dtd is referenced by PublicID in document both dtd > and css is resolved. But missing dtd shouldn't impact on rendering. Once > both dtd,css are resolved table is rendered well but otherwise it creates > additional blank cells (or blank space) in betwean each other. Is this you > have already reproduced as well? I meant the first point, sorry. The additional blank space between the table cells is caused by the missing Doctype. VEX currently renders tables different if insertion of content is not possible (and it is not possible because the Doctype is missing). The complete table system is a bit messy, but the main fix is to properly apply the selected Doctype.
(In reply to Carsten Hiesserich from comment #12) > (In reply to Kantor Jan from comment #10) > > (In reply to Carsten Hiesserich from comment #9) > > > > 2) Cursor still cannot be placed within the table cell even for internal > > > > document types. > > > > > > I can reproduce this behavior. Currently VEX loads the Doctype you select in > > > the dialog, but does not apply it completely. You'll also notice that the > > > content assist does not work in this case. > > > As a workaround, you can put the Doctype definition in your XML manually, > > > till this is fixed. > > > > I guess you mean 1st point not the 2nd. Doctype behaves the same in all > > versions in that manner that for undefined or defined documents by SystemID, > > document type has to be selected in dialog. DTD is then not resolved, only > > css for rendering. Once dtd is referenced by PublicID in document both dtd > > and css is resolved. But missing dtd shouldn't impact on rendering. Once > > both dtd,css are resolved table is rendered well but otherwise it creates > > additional blank cells (or blank space) in betwean each other. Is this you > > have already reproduced as well? > > I meant the first point, sorry. > The additional blank space between the table cells is caused by the missing > Doctype. VEX currently renders tables different if insertion of content is > not possible (and it is not possible because the Doctype is missing). > The complete table system is a bit messy, but the main fix is to properly > apply the selected Doctype. OK, I see. Sadly this works only with PublicID (given by extension point). Once dtd will be resolved fully with css for dialog document type selection it will be possible to use it even with SystemID.
Jan, can you check the new milestone M3? It contains all relevant bugfixes.
(In reply to Florian Thienel from comment #14) > Jan, can you check the new milestone M3? It contains all relevant bugfixes. Hello Florian, I'm sorry for the delay. I was bit busy. I tried the new version, CSS seems to be rendered well now, but : 1) Troubles with table remains the same form me. I can't still put cursor inside the table even for docbook. I found no log entry for this. 2) If I open sample document, it's ok but once I open another (e.g. just copy) I get error in Juno (after confirming the type selection dialog): !ENTRY org.eclipse.vex.ui 4 0 2013-10-16 10:17:55.711 !MESSAGE Unexpected error opening SampleDoc_sample.xml. Please report a bug at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Mylyn%20Docs%20Vex !STACK 0 java.lang.NullPointerException at org.eclipse.vex.core.internal.css.StyleSheet.flushAllStyles(StyleSheet.java:146) at org.eclipse.vex.ui.internal.editor.VexEditor.loadInput(VexEditor.java:380) at org.eclipse.vex.ui.internal.editor.VexEditor.createPartControl(VexEditor.java:496) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:129) at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:95) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:300) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:859) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:839) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:111) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:319) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:240) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:161) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53) at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:141) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:896) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:630) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:732) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:703) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:697) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:682) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.showTab(StackRenderer.java:1114) at org.eclipse.e4.ui.workbench.renderers.swt.LazyStackRenderer$1.handleEvent(LazyStackRenderer.java:67) at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:41) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4687) at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:187) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:81) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:171) at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:418) at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:385) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:579) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:315) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:985) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3079) at org.eclipse.ui.internal.WorkbenchPage.access$22(WorkbenchPage.java:3003) at org.eclipse.ui.internal.WorkbenchPage$8.run(WorkbenchPage.java:2985) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2981) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2940) at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:338) at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:180) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
(In reply to Kantor Jan from comment #15) > (In reply to Florian Thienel from comment #14) > > Jan, can you check the new milestone M3? It contains all relevant bugfixes. > > Hello Florian, > > I'm sorry for the delay. I was bit busy. I tried the new version, CSS seems > to be rendered well now, but : > 1) Troubles with table remains the same form me. I can't still put cursor > inside the table even for docbook. I found no log entry for this. > > 2) If I open sample document, it's ok but once I open another (e.g. just > copy) I get error in Juno (after confirming the type selection dialog): > Hello Jan, thanks for your feedback. I'm not able to reproduce this error with your sample files on 1.1M3-Juno, but what you are describing sounds like a problem we solved in the CI build some days ago. There was a problem with the table rendering when the CSS Style for colgroups was set to <table-row-group>. Did you possibly change your CSS or the document from the attached sample?
Created attachment 236567 [details] 1.1.0M3 css - error on 2nd document opening just replace attached sample plugin's css.
(In reply to Kantor Jan from comment #17) > Created attachment 236567 [details] > 1.1.0M3 css - error on 2nd document opening > > just replace attached sample plugin's css. Hello Carsten, I've not realized it and yes it's different, since I did some changes according M2 css 'block'.
(In reply to Kantor Jan from comment #18) > (In reply to Kantor Jan from comment #17) > > Created attachment 236567 [details] > > 1.1.0M3 css - error on 2nd document opening > > > > just replace attached sample plugin's css. > > Hello Carsten, > I've not realized it and yes it's different, since I did some changes > according M2 css 'block'. Yes that's what i assumed. This is already fixed in the Kepler CI Version. I'll merge the changes to the Juno branch in the next days. As a workaround you could remove the nested 'table-row-group' elements.
(In reply to Carsten Hiesserich from comment #19) > (In reply to Kantor Jan from comment #18) > > (In reply to Kantor Jan from comment #17) > > > Created attachment 236567 [details] > > > 1.1.0M3 css - error on 2nd document opening > > > > > > just replace attached sample plugin's css. > > > > Hello Carsten, > > I've not realized it and yes it's different, since I did some changes > > according M2 css 'block'. > > Yes that's what i assumed. This is already fixed in the Kepler CI Version. > I'll merge the changes to the Juno branch in the next days. > As a workaround you could remove the nested 'table-row-group' elements. Ok, I will clarify it for Juno then once your done. Anyway, have you detected or even fixed already the problem with caret in the table (Caret cannot be put in the table)?
(In reply to Kantor Jan from comment #20) > Ok, I will clarify it for Juno then once your done. Anyway, have you > detected or even fixed already the problem with caret in the table (Caret > cannot be put in the table)? That's in fact the same issue. The layout engine has problems with the nested 'table-row-group' so you can't place the caret inside. The Exception is only a side effect of this issue.
The Juno based CI version is now available at the following update site: https://hudson.eclipse.org/vex/job/mylyn-docs-vex.ci_juno/lastSuccessfulBuild/artifact/org.eclipse.vex.repository/target/repository/
fixed
closed
