Include/Upgrade own docx emitter in BIRT 4.13

[bbakan]

Hi,
until now we were using BIRT 3.2. We need to generate DOCX documents. For multiple reasons we could not use the DOCX emitter included in the BIRT development environment. So we wrote our own DOCX-emitter. The emitter works nice with BIRT 3.2. But unfortunately I was not able to integrate our emitter in the new BIRT version 4.13.
So I checked out the source from the original emitter (org.eclipse.birt.report.engine.emitter.docx_4.13.0.v202303021806.jar) from the repository and tried to install it in the BIRT plugin directory, just to figure out the emitter deployment. Replacing the original emitter. I used the steps which worked before with BIRT 3.2.

• Include the emitter project into my workspace from git/birt/engine/org.eclipse.birt.report.engine.emitter.docx
• Export the Plugin from Eclipse with Export->Plug-in-Development->Deployable plug-ins and fragments
• Copied the generated plugin to eclipse/plugins
  This does not work. I'm not an experienced Eclipse developer and the colleague who wrote our plugin is not available any more. What steps am I missing? Is there a step by step guide how to set up my environment to write a new emitter with the new BIRT version?
  I'm using the environment found in birt-report-designer-all-in-one-4.13.0-20230302-win32.win32.x86_64.zip
  EclipseConfiguration.txt
  Thanks for your help.

[hvbtup]

I cannot help you with the configuration/setup, but are you actually sure that you still need a custom emitter for DOCX?

What are the intended differences of the custom emitter in comparison to the output with the standard 4.13 DOCX emitter?

I know it was quite difficult to participate in the BIRT open source community long ago, but since the re-BIRTh this has become much easier.

So perhaps you'd be better off by describing the differences, compare the code and create PRs to integrate your changes into the standard DOCX emitter to get rid of the custom emitter.

I know what I'm talking about because I was in a similar situation.
I finally decided to fork the project a few years ago, in an attempt to have control over the changes - just a few months too early from today's point of view.
Some of my changes changed the behavior in a way that keeps me from creating PRs for them: They improve the Word output quality in a way, but at the price of losing some features.
For all the other improvements and bug fixes I coded over the years, I created PRs which were merged into the official repository.

Still, it is a significant amount of work to merge the changes from here to my fork to keep it up-to-date.

The idea of actually selling plugins is dead anyway IMHO.

So, anyone who thinks they need something fixed or improved in BIRT, I heartly recommend to participate in the development here instead of creating custom software. It is simply more efficient in the long run.

[bbakan]

@hvbtup Reasons, why the provided DOCX emmiter is not usable (and believe me we struggled a lot with this emitter):

1. We create large documents using the "Dyamic Text" Report Item. For each Instance of such an item the emitter generates a mht FILE. Opening a DOCX document with thousands of mht files in it the operating system is running out of file handles.
2. For each "Dynamic Text" Report Item the emitter creates a table surrounding it. So you end up with nested tables in a word document. Unfortunatly we have the requirement, that editing the generated document afterwards must be possible for a regular secretary.

If someone could help me to make our emitter run on the new version, I'll be happy to share the code. We don't sell our emitter it's for internal use only. We got rid of the mht files and only have one document.xml file in the output for the prize of reduced formatting options.

[hvbtup]

Your second issue is the main reason why I modified the DOCX emitter myself in the fork (https://github.com/triestram-partner/birt/).
Probably your code looks quite similar to the code there.
Otherwise, I'd be interested to see if you managed to develop a better solution than mine.

Regarding your first issue, I've never noticed this.
OTOH we don't create large Word reports.
Please try and see if this is still an issue with the tup_main branch of my fork.
You should not use the latest release there, however, because the web viewer is not working.

It would certainly make sense if you create a PR which fixes or improves the first issue, given it has no negative side effects.

Regarding the "lots of nested tables" issue:
Since we are at least two persons who tried to find a workaround for this, it would be useful to compare how we did solve it.
Maybe we can find a way to create a PR for the official BIRT code, for example by specifying a new emitter option to avoid nested tables at the cost of border/margin/padding capabilities.

[bbakan]

Sure, but first I need help setting up my environment to be able to compile any emitter.

[merks]

This should help:

https://github.com/eclipse-birt/birt#create-a-birt-development-environment