Since you mentioned that using a promise with a URL as the "src" is expected behavior, I think we can keep our current implementation as is

it depends from where the promise comes from, as i said if the promise comes from async handlebars helper it is fine, but if the promise is not coming from handlebars helper then it is just a coincidence that it works right now. i would let the promise behaviour only to handlebars helpers, for other execution like in scripts, just await the value.

I do have one additional question: when adding promise-based properties to the template’s "data", are there any limitations on what can be passed? Specifically, does the data need to be JSON-serializable, or can it include any JavaScript variable?

you can use any javascript value, jsreport wont complaint, unless you pass a value when another type was expected, but this depends on the libs you use, etc.

hi!

I suppose this is due to using the waitForAsyncHelper inside the docxImage

yes, this is the main reason, we want that user is able to get src image from async executions, like HTTP requests. so that waitForAsyncHelper, makes this to work:

{{docxImage src=(getImageFromServer) ...}}

async function getImageFromServer () {
  const result = await makeYourRequestHere()
  // result should be a base64 string representation of the image
  return result
}

Would it be reasonable to rely on this feature of the 'src' property, or is it better to strictly follow the documentation and provide a string value?

we expect this to work correctly when the async execution happens between handlebars helpers, in the example, getImageFromServer is an async handlebars helper, so this is expected to work.

as long as you do the async work from an async handlebars helper, it will work.

what is your use case? or what code are you trying to make it work by passing a promise?

hi!

yes, the introspect endpoint is a requirement when using HTTP requests to the jsreport HTTP API. right now there is no other way to authenticate the token against the authorization server.

i am opening a new issue to check what MS is recommending in this case (validate with the token signature and issuer validation in the OpenID discovery document). you can subscribe in the issue for updates about the feature, however we don't have am exact time when we will check this.

thanks, sounds like a good idea. i have created a new task for it. lets see when we get to it.

hi! there are no plans to support more engines for docx. the complexity there is already high, we don't want to complicate it more.

What makes using handlebars tricky for us is inability to address results of the function like
getData(this.order).name
I understand that by handlebars ideas data should be prepared beforehand, but it really overcomplicates things for us.

not sure if you are aware but, handlebars supports subexpressions, which will simplify your calls to this {{lookup (getData order) "name"}} (the lookup helper is a handlebars builtin helper FYI)

i have checked both templates, i will try to explain why each template does not work as expected.

in both of your templates the table is defined with text wrapping enabled

when this option is enabled it causes the XML of the paragraphs around the table (both the the one at the top and at the bottom) to be affected. what does this mean?

it means that visually the representation of the nodes in the template is like this:

• previous paragraph (visually the one at the top of the table)
• table
• next paragraph (visually the one at the bottom of the table)

however, internally the real representation in the XML is like this:

• previous paragraph (visually the one at the top of the table)
• table
• next paragraph (visually the one at the bottom of the table)

this behavior produces different results on each of your templates

for template v2

the template produces tables overlapping because this is the normal behavior of a table with text wrapping enabled when there is no text around. if you put two tables with text wrapping enabled and there are no paragraphs around them, the tables will overlap.

in this case the loop in the XML is represented like this

• paragraph 1 (start of loop {{#each}})
• table
• paragraph 2 (empty one)
• paragraph 3 (end of loop {{/each}})

in our docx processing if we detect paragraphs with no more text other than the handlebars calls, then after processing the template, these paragraphs are removed in order for them to not affect layout, so based on this the final result of the loop is this:

------ iteration 1 -----------

• table
• paragraph 2 (empty one)
  ------ iteration 2 -----------
• table
• paragraph 2 (empty one)
  ------ iteration 3 -----------
• table
• paragraph 2 (empty one)
  ------ ...continues... -----------

this is why the final result is overlapping tables, because for sibling tables (that have text wrapping enabled) to render correctly in MS Word the internal representation should be like this

• table
• empty paragraph
• empty paragraph
• table
• empty paragraph
• empty paragraph

how to fix the template v2?

you have two options:

• you can either disable the text wrapping in the table
• or prevent the paragraph that contains the end of loop to be removed, if you go with this option then you only need to put a leading space in the paragraph that contains the end of loop. so it should look like this <empty space here>{{/each}}

with either of these solutions you should be able to produce the expected result

for template v2.1

in this case the loop in the XML is represented like this

• table
• paragraph 1 (start of loop {{#each}})
• paragraph 2 (empty one)
• paragraph 3 (empty one)
• paragraph 4 (end of loop {{/each}})

as you can see, the problem is clear, the loop does not wrap the table, there is only empty paragraphs in the loop body, so this template does not produce anything meaningful

how to fix the template v2.1?

you have two options:

• you can either disable the text wrapping in the table
• or you can put the start of loop in a paragraph that is not around the table, you can create a new paragraph before the paragraph 1 and there put that start of the loop, just similar to the template v2

i hope this clarifies the reason of the results, we don't plan to do something to change the output when tables with text wrapping is enabled, as described there is easy solution for this just by changing the template. applying a solution that might try to "fix" this automatically will cause side effects on other cases.

this was recently added on master, not released yet.

hi!

for template v2.1 is clear that the issue is that the loop does not output anything, for template v2 what is the issue?

it is the that the rows are overlapping each other, right?

i have added to the backlog to check this case, we will get to it.

yes, i have it implemented in my local, i am now working on adding it to docxTable too for feature parity

i took a look today and this usage was never intended to work. as the docs shows, you should either use pptxTable as a row loop, or a vertical column loop.

you are trying to use the helper in two rows and this is not supported, you should try using the dynamic columns variation to get your desired layout.