I'm on Win10, using Acrobat Pro DC 2021.011... to edit and Reader DC (same version) to test.
From experience and from reading forums etc, forms in these apps are maddening... but I have not been able to find any discussion (or solutions) to the following behavior...
The form I'm building for other employees' use has a large edit text box set to Multi-line and Allow Rich Text Formatting. It is set to a default font, Calibri and size 50pt. For most situations this will work for them; provides 2-3 lines for a short product description. But occasionally they want a smaller font and more lines... They know how to get the ctrl+e properties bar. But in my testing of this alternative situation they'll need sometimes, I'm finding it's impossible to get the smaller font size and more lines to work. Here's my process.
tab into text box. Ctrl+E for properties bar.
before typing I set the font size to 24
then I type in my 4 lines of text
then I tab to my next form field...
and kaboom... the field I just filled...it's line height is so large it's pushed some of the content invisible. I assume this is coming from the field's default font size, 50
And if I try to adjust the line height, by selecting all the text and then choosing in More...>Form Field Text Properties>Paragraph>Line Spacing
If I set it to Single and click Close/click into another field I get the very large leading (presumably for 50pt font (same as pic above after point 5)
If I choose Exactly and set to point size slightly larger, click Close/out of field, I get another ridiculous result where the 2/3 line have the height I set, but the space between the 1 & 2 second line is way too much and the space between the last line and 3rd line is way too small...
before tabbing or clicking out of field to another field
Good lord.. what is that! 3 different leading values in the same field; just after applying 1 value to all lines, all text in the field...
It makes no sense... it doesn't look like it regards your input at all, and just comes up with it's own random leading... I've fiddled with Space before/after and combinations of Line Height and nothing comes close to what we need... At this point I'm convinced the Acrobat tools for a stylizing text in a multi-line, allow formatting text field are useless. I'd be better off with my employees they can't format anything, ever. Just type one line and hit Tab or Enter...
What is going on! I'm trying to make a simple fillable form for other employees to use, but this kind of behavior makes that impossible (It's enough of a stretch to teach them to use the ctrl+E and do some styling of their text but this is bonkers and completely unteachable... there's not rhyme or pattern to teach!)
Hope someone can help or has seen this behavior too.
Related
I am working on an app with a chat feature that shows messages in a ListView. The size of each "message" depends on the amount of text in that particular message.
I would like to put a limit on the number of lines, say 10 lines max. If a particular message happens to take up more than the limit, the text should be truncated near the end of the 10th line and a "FlatButton" with the text 'more...' be provided, which allows the user to open up that message to see all the text. For messages that fit, this button will not be shown.
The part I am struggling with is being able to truncate the text at the right point.
Currently I am thinking that guessing the number of lines a message might take up based on the number of characters and the font size would be the best approach, with the limitation that sometimes it might be off by a couple of lines. That is probably acceptable in this application.
As a bonus I also would like to render the "more..." button "inline" at the end of the text, but that is probably a separate question.
Did you try the maxLines property of Text widget? This in combination with overflow should solve your problem.
Reference
maxLine property
overflow property
I'm working on a document describing keyboard shortcuts in GNOME and want to make text better looking than: ALT + TAB. A common way seems to be like in this thread where the buttons appear to be within the text:
https://unix.stackexchange.com/q/465681
Is this possible in LibreOffice in a proper way, or is it just inserting images inline? That doesn't seem like it would work every well with changing font size, etc. later, so I was hoping for a better solution.
You could insert real push buttons that don't do anything by following steps 1 thru 6 outlined at https://help.libreoffice.org/Common/Inserting_and_Editing_Buttons. But that approach, as well as inserting inline images, would be awkward because you'd have to worry at least about sizing, anchoring, and wrapping of surrounding text.
The approach you appear to be trying to avoid seems much more palatable, so long as you're not looking to exactly duplicate to Stack Exchange look.
As an example to demonstrate that it's workable, I did the following by applying the same Character formatting settings to each key word. This involved changing font family and size, setting light gray highlighting, adding a gray border, and changing left and right border padding from 0.02 to 0.06...
To make things easy, the settings could all be done with a single button press by creating a macro that could be applied to selected text. And since the result is just formatted text, there are no sizing, anchoring, or text wrapping issues to worry about.
One other option, as an alternative to significant text formatting, is to acquire and use a keyboard font, such as that discussed at How is the Keyboard font automatically styled as keyboard-like keys for the letters in Alt, Shift, Ctrl, Esc, and Backspace?. That would only require changing to that font to type in key representations.
We use TinyMCE as the wysiwyg editor for our content builder. You can drag and drop a text module and once you click an edit button an TinyMCE instance will open. This works really well.
Problem is now that the builder is made for designers so a lot of the times you add a text module just for a 1 word heading or other cases where you only have one block. (one h1, one p etc.) You can also see this behavior in the official demos: Just add an lonely h2 heading, select all text and start to write.
Now Tiny MCE has the default behavior that if you select the complete text (which is almost always the case if you for example change an 1 line / word heading) and you start typing you will lose your formats completely. ( in our case: color, font-size, font-weight, line-height etc.)
This makes editing an heading for example really painful. Best workaround so far is to leave 1 character to not lose the format and then delete the character in the end.
I never saw that behavior in other editors so my question is: Is there maybe an easy setting or workaround to avoid this?
If there are situations where you want a root element to be something specific (e.g. <h2>) you can use the forced_root_block setting on that instance of TinyMCE to force a specific element:
https://www.tinymce.com/docs/configure/content-filtering/#forced_root_block
Even if you delete all text the new text will be wrapped with that root element. See this TinyMCE Fiddle for examples:
http://fiddle.tinymce.com/SOfaab
I think this would address your one line issue?
When a form text field is inserted in a Word document, the grey shaded length is about 5 characters long. How can this length be increased?
Allthough it is a rather crude measure (and I don't recommend it), you can set "Properties -> Default Text" to as many blanks as you want the size. But this comes for a price: as long as you move into the field by pressing TAB, all blanks are selected and get typed over. When you use the mouse, you click the cursor anywhere into the field and start typing ... so your entry might be pre and post fixed by a number of blanks that you have to trim away in e.g. an exit macro.
I recommend old form fields as the last resort (i.e. there must be a good reason to use them) and would prefer (in that order)
native Word2010/2007 fields (text or Rich text - perhaps not backwords compatible)
legacy ActiveX fields (compatible with W2003)
Legacy (old) form fields
I have a Crystal Report 11 file that is a letter. The first Details section contains a large text box that has print date, address block, and the salutation line. Every once in a while, the last line of the text box gets cut off so that the salutation isn't seen. It's very inconsistent in that sometimes, I run the report for one person in my system and the text is cut off, but if I run the report a few hours later for the same person, without having changed the values of the address or name in my database, then the letter looks fine.
I increased the text box height and the Details section height, but the problem still occurs intermittently. Has this happened to anyone else, or does anyone have an idea what could be causing this?
Normally this should be working if you check the "Can Grow" option in the common tab of the "Format Field/Text" settings. With that option checked it shouldn't matter which height you set.
This is difficult problem that you have to attack from 3 different fronts:
Software Hot Fix
Default Printer
Form Authoring
Software Hot Fix: You'll need to download the CRRuntime that includes Hot Fix 20. This Hot Fix addresses truncation problems when making a PDF. You can find it at http://downloads.businessobjects.com/akdlm/crnetruntime/clickonce/CRRuntime_64bit_13_0_20.msi
Default Printer: The printer you use when authoring a report must match a printer when you are rendering a report. On our servers, there are no printers installed except the Microsoft XPS Document Writer. Be sure to select that as your default printer when writing the report.
Form Authoring: When you add a database field to your report, don't drag it from the field explorer onto the design surface. First insert a text object onto the design surface. When you've positioned and sized it, then drag the database field onto the Text Object. For whatever reason, the database field will wrap better when it is enclosed by a text object.