Whitespaces around code blocks

[DylanSnel]

Hey man,
Again, great work on the package.
Just another feature that i would think could really help.

Right now it feels like with highly dynamic content whitespace manangement is kind of tough.

I had to resort to this and color coding to make it easier on myself, but it needs to look like a clusterfuck of brackets and then still i have additional paragraphs in the resulting document.

I was already checking out the code to see if i could figure out myself on how to fix it, but unfortunately i struggled to figure it out.

I think what would should be made is a way to remove the paragraph surrounding a block if the block is the only content of the paragraph. and force the user to make paragraphs and whitespace within the block if they want to. This gives users better control

[Amberg]

Hi Dylan,

Great to hear you're finding the library useful! If you haven't already, I'd appreciate it if you could give it a Star

I've thought about implementing something along these lines, but it's a bit more complicated. Empty paragraphs are already removed, so what you're describing is essentially already implemented. However, consider the following scenario:

Current Implementation:

<p>text</p><p>{{.Placeholder}}</p><p>text</p>
becomes
<p>text</p><p>text</p>

That means, even if the paragraph with the palceholder is removed, There is still a newline in de document

I think what you're suggesting is a "merge" of the two adjacent paragraphs. But how do we distinguish between an intentionally created paragraph and one that was added just for better readability?

I've thought of two ideas so far

Remove Adjacent Line Breaks

Always remove the adjacent line breaks <br>, "shift-enter") around a placeholder. This would mean that if you really want a line break in the result, you'd have to insert two <br> tags.

Introduce Explicit Syntax

Make this explicit by finding a new syntax for it. It should be concise, but I haven't come up with any clever ideas yet.
Let me know if you have any good ideas

Btw:

I noticed in your example that there's an undocumented feature called ModelProperty To specify a default formatter. While it doesn't solve the "clusterfuck" 😆 But it does make the template a bit less cluttered. Unfortunately, I haven't gotten around to documenting this feature yet.

[DylanSnel]

Ah i didnt know it auto removed nulls so ive been using ifs. But you could device with an if or a list a new method {{#Images}cp} Cp meaning clear paragraph or somthing Ill post more on my pc later

…

On Tue, Mar 4, 2025, 19:06 Manuel Amstutz ***@***.***> wrote: Hi Dylan, Great to hear you're finding the library useful! If you haven't already, I'd appreciate it if you could give it a Star I've thought about implementing something along these lines, but it's a bit more complicated. Empty paragraphs are already removed, so what you're describing is essentially already implemented. However, consider the following scenario: Current Implementation: <p>text</p><p>{{.Placeholder}}</p><p>text</p> becomes <p>text</p><p>text</p> Ant that means, even if the paragraph with the palceholder is removed, There is still a newline in de document I think what you're suggesting is a "merge" of the two adjacent paragraphs. But how do we distinguish between an intentionally created paragraph and one that was added just for better readability? I've thought of two ideas so far Remove Adjacent Line Breaks Always remove the adjacent line breaks <br>, "shift-enter") around a placeholder. This would mean that if you really want a line break in the result, you'd have to insert two <br> tags. Introduce Explicit Syntax Make this explicit by finding a new syntax for it. It should be concise, but I haven't come up with any clever ideas yet. *Let me know if you have any good ideas* Btw: I noticed in your example that there's an undocumented feature called ModelProperty <https://github.com/Amberg/DocxTemplater/blob/dc85810505b47ad81b2c6eb3589c239ca4f730fd/DocxTemplater.Test/TimeTrackingTemplateTest.cs#L66>. While it doesn't solve the "clusterfuck" But it does make the template a bit less cluttered. Unfortunately, I haven't gotten around to documenting this feature yet. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKVXQIR6Q3F5VT7UYIPUZT2SXTSNAVCNFSM6AAAAABYJQWWU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJYGQ4TGMJTHE> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: Amberg]*Amberg* left a comment (Amberg/DocxTemplater#52) <#52 (comment)> Hi Dylan, Great to hear you're finding the library useful! If you haven't already, I'd appreciate it if you could give it a Star I've thought about implementing something along these lines, but it's a bit more complicated. Empty paragraphs are already removed, so what you're describing is essentially already implemented. However, consider the following scenario: Current Implementation: <p>text</p><p>{{.Placeholder}}</p><p>text</p> becomes <p>text</p><p>text</p> Ant that means, even if the paragraph with the palceholder is removed, There is still a newline in de document I think what you're suggesting is a "merge" of the two adjacent paragraphs. But how do we distinguish between an intentionally created paragraph and one that was added just for better readability? I've thought of two ideas so far Remove Adjacent Line Breaks Always remove the adjacent line breaks <br>, "shift-enter") around a placeholder. This would mean that if you really want a line break in the result, you'd have to insert two <br> tags. Introduce Explicit Syntax Make this explicit by finding a new syntax for it. It should be concise, but I haven't come up with any clever ideas yet. *Let me know if you have any good ideas* Btw: I noticed in your example that there's an undocumented feature called ModelProperty <https://github.com/Amberg/DocxTemplater/blob/dc85810505b47ad81b2c6eb3589c239ca4f730fd/DocxTemplater.Test/TimeTrackingTemplateTest.cs#L66>. While it doesn't solve the "clusterfuck" But it does make the template a bit less cluttered. Unfortunately, I haven't gotten around to documenting this feature yet. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKVXQIR6Q3F5VT7UYIPUZT2SXTSNAVCNFSM6AAAAABYJQWWU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJYGQ4TGMJTHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DylanSnel]

@Amberg I cant really use the modelproperty since i want to expose template building to clients.

Also please look at the following from a template

This looks way cleaner if we could do like this, but for that to work i believe the paragraphs that are marked by the red arrows should be removed (this of course also means the prefixing <p> of the if statement and the closing block.)

In my opinion this will always we be the best case and this cal always be done if the opening and or closing bracket are the entirety of the paragraph. The same goes for lists.

To get a <ul> working i had to jam everything withing one line otherwise id get way to much white-space.

So i think if we just remove those <p> tags i mentioned I think it would be great. Like i said before i tried to comprehend how the code is actually finding all that, otherwise i wouldve made another pr

[DylanSnel]

@Amberg Any thoughts?
This is an important feature for me and im willing to fund 20 euros if that helps

[Amberg]

Yes, the feature is definitely a good idea, and it is on the roadmap.

However, I first want to complete the current beta since I need "Chart" support.

Next, I will focus on the five tickets labeled as "Enhancement," as this ticket is part of that as well. The solution for the whitespace issue is not that simple, though. I still need to test it in different scenarios. Right now, I’m leaning towards removing the next <br> (Shift-Enter) or introducing a custom syntax for it.

That said, I can’t promise when I’ll get to it, as I’m working on this in my free time.

[DylanSnel]

Sounds like a plan! Maybe ill take a stab at it

…

On Thu, Mar 13, 2025, 18:29 Manuel Amstutz ***@***.***> wrote: Yes, the feature is definitely a good idea, and it is on the roadmap. However, I first want to complete the current beta since I need "Chart" support. Next, I will focus on the five tickets labeled as "Enhancement," as this ticket is part of that as well. The solution for the whitespace issue is not that simple, though. I still need to test it in different scenarios. Right now, I’m leaning towards removing the next (Shift-Enter) or introducing a custom syntax for it. That said, I can’t promise when I’ll get to it, as I’m working on this in my free time. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKVXQLV2YRYCP2HSUXPS2L2UG6BNAVCNFSM6AAAAABYJQWWU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRSGEYDONZUHA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: Amberg]*Amberg* left a comment (Amberg/DocxTemplater#52) <#52 (comment)> Yes, the feature is definitely a good idea, and it is on the roadmap. However, I first want to complete the current beta since I need "Chart" support. Next, I will focus on the five tickets labeled as "Enhancement," as this ticket is part of that as well. The solution for the whitespace issue is not that simple, though. I still need to test it in different scenarios. Right now, I’m leaning towards removing the next (Shift-Enter) or introducing a custom syntax for it. That said, I can’t promise when I’ll get to it, as I’m working on this in my free time. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKVXQLV2YRYCP2HSUXPS2L2UG6BNAVCNFSM6AAAAABYJQWWU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRSGEYDONZUHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Amberg]

@DylanSnel See: #71
I hope to release this as a beta soon, but I would really appreciate your feedback. In my tests, it made the templates significantly more readable.

[DylanSnel]

Awesome man i'll take a look!

[DylanSnel]

@Amberg I tried updating but i dont see the property on the Processettings object

[DylanSnel]

Im getting some great results now in my fork. I made some changes to remove paragraphs and this works great.
Ill have to see how to make a pr from my fork to yours and you can review it|

Edit: Shame i broke old functionality so making a PR isnt that easy yet. What i mean is if i turn my new setting of it doesnt function anymore.

[Amberg]

@DylanSnel
Yes, removing paragraphs definitely isn't a simple task—there are so many edge cases to think about. I’m thinking of things like tables, page breaks, paragraphs inside tables, and paragraphs in lists.

But maybe it's not quite as bad as I initially thought. Let me know if I can help with anything! But I'm still curious—why isn’t a regular line break (Shift+Enter) enough in your case?

[DylanSnel]

@Amberg Because i want to switch entire sections of my documents on or off and i want some of my more technical customers to be able to make styling changes to a document without getting scared of the handlebar clusterfuck.

I basically have questionnaire in my app that I would like to generate a document for. So without this my document would generate so much enters or give weird styling, because per question we can have different answer types which in some case need different styling, which is hard to manage because word treats paragraphs as breaks in the style. (The switch case you provided in issue #46 will be another great improvement to this )

For instance the bullet points in the instance above look at the difference i have in my original document

where i had to put my image list into my bullet points because otherwise my entire documents would have many spaces even tough the `{{.MultiResponse}} is not filled for this particular question. With removing the empty paragraph of the closing that i can clean that up like this below

I tried to let AI help me do this but unfortunately it keeps breaking things. After some research I got a better understanding in how your code works. I think the following steps are needed:

• Find all paragraphs containing Opening and or Closing tags
• Mark them with some attribute
• In the clean up stage find all marked paragraphs
  • If empty: Remove the entire paragraph
  • If not empty: Clean up the attribute

Do you see any fault in this ?

[DylanSnel]

Addtitionally ill provide you with my realistic outcome

this the result when using

This is because the line below is a paragraph end and start which is needed for the bullets to work. You see the paragraph tag is bleeding through the ifs (thats why i color code my code so much so i can see what remains) and you can clearly see its an orange paragraph tag. If that makes sense

[Amberg]

@DylanSnel

 Find all paragraphs containing Opening and or Closing tags
Mark them with some attribute
In the clean up stage find all marked paragraphs
If empty: Remove the entire paragraph
If not empty: Clean up the attribute

Yes this could work.

This doesn't directly solve your problem, but I have a few tips for your template:

• With the correct error handling mode, tags with null values are automatically removed — so you can skip manual null checks.
  Drawback: Real errors might go unnoticed.
• A null list is treated as an empty list — no check required.
  Alternatively, you can initialize the list in your model’s constructor, which is generally a good practice.
• Initialize all null properties in the constructor with appropriate empty values.
• Avoid adding logic to your template. Keep as much logic as possible in the model class.
• Use the [ModelProperty] attribute for formatters. The user can still override the property's formatter.
  Example