nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Birt 4.3 - Doc/DocX emitters producing low fidelity outputs

Tomas.Vala

Hi guys, i am facing an issue related to fidelity of Doc/DocX emitters' output. Resulting documents simply deviate way too much (layout or style wise) from source rptdesign templates. Source rptdesing templates in subject are simplistic in terms of content and layout, by far nothing spectacular, no graphics or decorations, just text formatted in a specific way. Birt Doc/DocX emitters apparently fail to translate basic stuff like certain grid margins, element margins. It's really disappointing to get simplistic rptdesign butchered in a such degree. Now imagine what may happen if more complex rptdesigns were being used. rptdesign -> PDF: OKrptdesign -> HTML: OKrptdesign -> Doc: way too badrptdesign -> DocX: way too bad Samples attached. I am wondering is this expected behavior of named emitters? If by chance only a subset of rptdesign features is designed-intended to be translated to DocX output, is that documented somewhere? Why would anyone think margins omission is a good idea though.

Related note 1: In comparison to Doc/DocX emitters integrated in Birt, commercial emitter from Arctorus gives initial impression of producing perfectly looking DocX outputs but that is just an illusion. They apparently achieve layout fidelity by positioning individual document elements using float-text element feature intensively. Resulting document therefore is an opposite to typical Word document, consists of large amount of floating fragments scattered all over the place, unfriendly to human edits, completely pointless. It's almost as bad as taking a screenshot of a PDF page, attaching it to a DocX and calling result a Word document ;-) Related note 2: Now onto something real mind-boggling. I am getting better (far from perfect) results by engaging pretty crazy toolchain like rptdesign --Birt--> Html --TidyJ--> HtmlX --DocX4J--> DocX, than by letting Birt process rptdesign to DocX directly. I have achieved even better results by performing PDF to DocX conversion using free online services, than by letting Birt process rptdesign to DocX directly. That's not precisely what I would expect to say the least... Anyone willing to comment on this? Thanks. Cheers,Tomas

Find more posts tagged with

Comments

mwilliams

Can you attach a .rptdesign file that I can run and test on? Thanks.

Tomas.Vala

Hi, I can't attach the original rptdesign as it wouldn't work in isolated environment (uses rptlibrary and specific data access plugin). Will manage to prepare a simplistic rptdesign to demonstrate the case though. For the record, my rptdesigns and rptlibrary were initially created using Birt 3.7 (iirc) and last saved using Birt 4.2. I re-saved them using Birt 4.3 designer before taking these new tests. During the process of evaluating Birt 4.3 upgrade I've encountered another surprise: setting "Page Break Before: always" is suddenly ignored on one of my reports (works as expected on Birt 4.2, PDF emitter). I am yet to have a proper look at it and if it really turns out to be a persistent issue of Birt 4.3 I will attempt to prepare a demo rptdesign. Regards,Tomas

mwilliams

I'll keep an eye out for a sample report showing your issues that I can test on.

Tomas.Vala

Sorry for the late response. I've been on tight schedule busy workarounding the issues. Will post sample rtpdesign to showcase DocX issues later on when it's ready. As for the DocX unrelated paging problem, I am unable to reproduce it any longer. Perhaps a false alarm.

mwilliams

Possibly. Did the data change between runs of the design? If so, it could be data specific. Like a certain size of a row forced the odd page break.