Please give solution for unwanted oversize column of HSN, when we convert it to PDF.
Example mentioned in below link too.
https://www.manager.io/guides/10388
You would need a custom theme with logic to individually set the column width of line item custom fields. That is far beyond the scope of this forum.
@Tut such issues should not be forced as a responsibility of the user. the user has only entered what is necessary and it is the program that needs to wrap the column as per content.
@lubos kindly look into this as this is a known issue for a long time already.
1 Like
This is not an issue of wrapping. This is a case of the user not liking the graphic layout of a form. Nothing is forced on the user for the program to function correctly. But if the user wants to redesign the form, a custom theme will be required.
this is an issue of wrapping with the internal pdf generator and not the users’ dislike for the graphic layout of a form.
below is an invoice displayed in Manager.
below is the pdf generated using the PDF button.
I beg to differ, @sharpdrivetek, but that is not a wrapping error. The Description column text wraps in both your examples, as it is designed to do. That is, the text is broken into multiple lines based on the allocated column width. And the HSN column wraps in neither, also as designed. The issue is that more width is allocated to the line-item custom field column, HSN, than you or @sales.newtech might prefer in the PDF version.
The reason is that the three righthand columns have defined column widths based on a column index in the theme code. The remaining space is divided according to the internal rules of the HTML or PDF generator, which are obviously different. The HTML version seen onscreen uses only as much space as necessary for the HSN column and allots the remainder to Description. The PDF version allots half the unspecified width to each.
The reason the HSN column cannot be fixed (and therefore narrower) is that it is a line-item custom field, and in some cases that field might be longer than an HSN code. This is a matter of how HSN codes were accommodated in the program. You need to remember than display of HSN codes used available features of the program to meet a requirement unique to India.
sorry but you are simply over-complicating the issue.
in a pdf the description column can use as much space as it wants if the line item custom fields are programmed to wrap as per the size of its content. this is the only issue which need to be addressed.
I am sorry, but things are not as you apparently think they are. The line-item custom field is already programmed to wrap. (Try it. Enter a really long string of text into a line-item custom field. It will eventually wrap.) What the line-item custom field column is not programmed for is a fixed width. So there is no “reserved” width for it.
My testing shows that the HTML generator divides remaining, unspecified width based on relative length of text in the two columns. So column widths can vary. On the other hand, the PDF generator evenly divides unreserved width no matter how much is actually required for either column. What this really comes down to is how the two generators make the decision to apportion width among the columns that are not fixed. The HTML generator does it proportionally, according to amount of text, in order to minimize overall number of lines. The PDF generator does it evenly. No doubt, that simplifies PDF creation for multiple languages.
please understand that wrapping is not limited to long strings.
in my above example, if my item description was another x5 longer and i added another 5 similar line items, then the pdf would be two pages. it could be a single page had the other column (in this case HSN) wrapped just to the width of the actual content in it thus enabling the item description to utilize more horizontal space.
there is no point in arguing that the internal pdf generator is designed that way. i know that already and this is exactly what I am suggesting to be improved.
I know that. But text will not wrap until the available width limit is reached. My point was that you are suggesting that the custom field column be wrapped, while it already is. That is why I say it is not a question of wrapping, but of how the generators allocate width when column width is not fixed.
I completely understand what you are asking for and why. I am only saying that the solution does not lie in wrapping. It would require determining the size of the entry and adaptively fixing the column width.
I too would like this custom column issue resolved so the PDF version could have similar ‘wide as necessary’ rule as it does for the print version.
This is very annoying for professional document for clients
1 Like
I am facing the same problem as well, nothing too serious, but I believe that the easily customizable look and feel of documents is a huge selling point for Manager, this is how I sold it to many of my clients. The PDF button helps with keeping headers and footers in place but messes up the tables column widths and nested tables in line descriptions.
Is this already resolved? I’m facing the same issue right now (v22.9.26.402).
In Manager.io it shows everything just fine, but once converted to PDF, the ‘Description’ isn’t wrapping (whole lines) and the custom field column is allocating to much white spacing.
How are you converting it to a pdf?
Converted with the built-in PDF generator.
The PDF converter is rendered obsolete by the Developer and thus no longer supported. One is advised to use the Print function (to PDF) instead and if needing to email to send the PDF as attachment using your normal email application and not Manager.
There are plenty discussions about this on the forum (search it) and for the unforeseeable future do not think @Lubos will change his mind and restore this in my view useful functionality.