Disclaimer: I am new to the forum and to Madcap Flare, I have tried looking for a solution to my issue in the forum and with online help but couldn't find it. However some of you might be able to point me to the right page/solution.
Issue: I have several tables in my project that automatically resize when changing to PDF view and when printing in PDF, as you can see in the screenshot. The problem is that the first row always resizes automatically.
I have tried assigning defined values to the columns width both in percentage and in pixels. I also chose in the paragraph settings for the first column to "Never Hyphenate". That only works when I select it, if I save or switch to the text editor, then it goes back to the layout you can see in the screenshot.
Can anybody help me solving this issue?
Thanks,
You do not have the required permissions to view the files attached to this post.
I've run into this problem before, and it usually has something to do with content in the other columns (not the one getting squished) not being able to fit in the cell correctly, which can happen with long unbroken words (such as filenames) or large images.
awells12 wrote:I've run into this problem before, and it usually has something to do with content in the other columns (not the one getting squished) not being able to fit in the cell correctly, which can happen with long unbroken words (such as filenames) or large images.
Yes, I think that's the issue. Usually in the "Description" column there are line codes which don't brake up automatically. In the paragraph options, I've tried applying the max. hyphenation (short words, many lines) but, although the lines are now split into many lines, it didn't solve the issue.
Nita Beck wrote:Try setting the width of the table to 100% rather than auto. Does that help?
I've tried setting it to 100% and even playing with the fixed width (either percentage or pixel) assigning more width to the first column, but unfortunately with no luck.
zoltan__v wrote:I've tried setting it to 100% and even playing with the fixed width (either percentage or pixel) assigning more width to the first column, but unfortunately with no luck.
So if you set the first column width to something ridiculous like 80 or 90% it still happens?
I sympathize, and I wish I had an answer for you. I've battled the same thing with table columns for a few weeks and haven't figured anything new out. If it didn't take so much time, I would scrap the table tag all together and build a table-looking thing using divs -- though I am not sure how easy that would be to edit and add on to. This was an interesting resource: http://divtable.com/converter/.
I posted on a different forum that deals with this. Perhaps some of the suggestions can help you: viewtopic.php?f=6&t=13391. I do not yet have Flare 2017, but I'm hoping this has been addressed.
Flare is an awesome tool, but this quirks and nuances are driving me crazy!
<table class="TableStyle-ti_IndentedBasicTable" style="mc-table-style: url('../Resources/TableStyles/Standard.css');" cellspacing="0">
<thead>
<tr class="TableStyle-ti_IndentedBasicTable-Head-Header1" style="height: 52px;">
<th class="TableStyle-ti_IndentedBasicTable-HeadE-Column1-Header1" style="mc-hyphenate: never; border-right-style: none; border-bottom-style: none; padding: 4pt 4pt 6pt 5pt;">HTTP Method</th>
<th class="TableStyle-ti_IndentedBasicTable-HeadE-Column1-Header1">URL</th>
<th class="TableStyle-ti_IndentedBasicTable-HeadD-Column1-Header1">Description</th>
</tr>
</thead>
<tbody>
<tr class="TableStyle-ti_IndentedBasicTable-Body-Body1">
<td class="TableStyle-ti_IndentedBasicTable-BodyE-Column1-Body1">GET</td>
<td class="TableStyle-ti_IndentedBasicTable-BodyE-Column1-Body1" style="mc-hyphenate: always; mc-hyphenate-shortest-word: 5; mc-hyphenate-shortest-prefix: 3; mc-hyphenate-shortest-suffix: 3; mc-hyphenate-maximum-adjacent-line-count: 4; border-right-style: none; border-bottom-style: none; padding: 4pt 4pt 6pt 5pt;"><code><BaseUrl>/AvailableAuthMethods</code></td>
<td class="TableStyle-ti_IndentedBasicTable-BodyD-Column1-Body1">Returns a string with the list of configured authentication methods. The authentication methods are separated by semicolon.</td>
</tr>
</tbody>
</table>
This could be far off but: It looks like you're using a Table Style--have you tried right clicking on each column at the top of the XML editor, selecting Column Style at the bottom (the last option), and then select the column which has a set percentage width.
When I do this for each column, I've found my columns widths are less likely to change on its own.
Technical Writer using and experimenting with Flare version 12.0.5991.
paintedturtle wrote:This could be far off but: It looks like you're using a Table Style--have you tried right clicking on each column at the top of the XML editor, selecting Column Style at the bottom (the last option), and then select the column which has a set percentage width.
When I do this for each column, I've found my columns widths are less likely to change on its own.
Yeah, I have tried the above but with no luck unfortunately. The output stays the same
This is a long standing bug which unfortunately has yet to be fixed. This is a problem for those of us who create documentation for programming example with e.g. long URL links or long lists of numbers / characters without a space e.g. for API keys, etc. Not splitting the text seems to take priority over column width setting whereas the opposite should be the case. Please submit a bug
iand wrote:This is a long standing bug which unfortunately has yet to be fixed. This is a problem for those of us who create documentation for programming example with e.g. long URL links or long lists of numbers / characters without a space e.g. for API keys, etc. Not splitting the text seems to take priority over column width setting whereas the opposite should be the case. Please submit a bug
Thanks iand, I though it might be, but was hoping not... I will submit a bug.
Of all the bugs that I've encountered in MadCap Flare 10 that I've been using over the last few weeks, this is the most infuriating. I have spent days putting together a complex table with multiple code samples, and I find out at the end that I cannot control the column widths as I need in the printed output. I then have to resort to unprofessional workarounds such as decreasing font sizes, and so on.
I hope that the fix will make it into Flare 10 before too long.
johnnygreen wrote:Of all the bugs that I've encountered in MadCap Flare 10 that I've been using over the last few weeks, this is the most infuriating. I have spent days putting together a complex table with multiple code samples, and I find out at the end that I cannot control the column widths as I need in the printed output. I then have to resort to unprofessional workarounds such as decreasing font sizes, and so on.
I hope that the fix will make it into Flare 10 before too long.
I very much doubt that MadCap will go back to fix something in a version of Flare that is now several versions out of date. We're up to Flare 2017 (aka Flare 13) as of this writing. I'm not suggesting that Flare 11, 12, or 13 fixed the bug you're experiencing; would need to do some research on that and perhaps someone who does know can add to this discussion. Rather, I'm just saying that you shouldn't expect any bug fixes to Flare 10.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
johnnygreen wrote:Of all the bugs that I've encountered in MadCap Flare 10 that I've been using over the last few weeks, this is the most infuriating. I have spent days putting together a complex table with multiple code samples, and I find out at the end that I cannot control the column widths as I need in the printed output. I then have to resort to unprofessional workarounds such as decreasing font sizes, and so on.
I hope that the fix will make it into Flare 10 before too long.
I very much doubt that MadCap will go back to fix something in a version of Flare that is now several versions out of date. We're up to Flare 2017 (aka Flare 13) as of this writing. I'm not suggesting that Flare 11, 12, or 13 fixed the bug you're experiencing; would need to do some research on that and perhaps someone who does know can add to this discussion. Rather, I'm just saying that you shouldn't expect any bug fixes to Flare 10.
It's certainly not fixed in the latest version of Flare.
Flare is pretty awful when it comes to tables to be fair, but ignoring styles on print outputs is criminal.
Glad to at least discover that I'm not crazy or inept when it comes to tables.
I know Flare is optimized for web output but a lot of companies are slow to transition or resistant to moving everything to web. I feel like I'll be working in PDF format for a long time. Wish Flare would prioritize issues like these.
I've ran into the same issue. I've submitted a bug.
I need PDF output to supplement online output from this project.
If Flare can't put out an appropriate PDF file, I will be extremely disappointed.
Valiant wrote:I've ran into the same issue. I've submitted a bug.
I need PDF output to supplement online output from this project.
If Flare can't put out an appropriate PDF file, I will be extremely disappointed.
I was able to manually manipulate the contents of the table to make the output work. It was either that or to put the document into Framemaker.
I hope for a real fix.
Greetings. Was a solution found for this? Is there a bug reference I can can go vote up? I am having the same issue. I need to force wrap long property names in the first column of a table. I can make it work in HTML using CSS, but the PDF output ignores all of my attempts. I can insert a soft <br/> but then if a user searches for the full name, it will not be found.
Update: I found a hack that solves my immediate problem, but I hope there is a better CSS solution available.
In my case, the failure to have long strings break in the first column was causing the fourth / last column to be so narrow the text did not display in an optimal way. I create a blank image 80 pixels wide by 1 pixel tall and inserted that into the last line of the fourth column. It took a few trials to determine the best width. This forces the fourth column to display at my desired with in HTML and PDF output. Further, some of the strings in the first column are now breaking.
<td>
<p>Controller</p>
<p>zzzzzzz</p>
<p>zzzzzzz</p>
<p>zzzzzzz<br /><img src="images/80_col_width.png" /></p>
</td>
However, now I see that even when a string breaks in this fashion, it still cannot be found by the search. I suspect there is no solution for that part of the problem.
When I have long parameter names in tables (or even headings) that cause problems with text being too long for the space allocated for it, I use a Zero Width Space (ZWSP) character (​), inserting it where the break could occur. The advantage is the text won't wrap unless it is necessary. There is no visual cue in the output that this has been inserted. But it does break the search functionality, though I doubt in my output that many people are searching on parameter names. One big downside is after you insert the ZWSP code, it isn't visible after you save the file but it remains there if needed.
You do not have the required permissions to view the files attached to this post.
