I am having an issue using Adobe LiveCycle Designer in conjunction with iTextSharp. I have a multi-line text field that I'm stamping That looks like...
Blah blah text here: _________________
______________________________________
______________________________________
In LiveCycleDesigner, I have a single field that encapsulated all 3 lines (including the static text). I've set the font/paragraph settings so that the first line indents over to where the field starts, the field aligns vertically, and the lines are spaced properly.
When I use PdfStamper to set the fields (without flattening the form), it looks fine in Adobe (though Chrome and Firefox default plugins don't seem to support AcroForms very well). When I flatten the form, though, I lose everything but the font.
Does iTextSharp just not support the ability to do this? Is there some better way I should be doing this? I'm trying to build a generic form builder for my application, so a one-off fix won't really be useful for me.
The only alternative I've thought of is to break it into 3 fields on the PDF and use some clever grouping and MeasureString() (UGH) to determine how much of my string can fit in each field. Can anyone think of anything better?
Related
I think this should be a relatively straightforward question to answer: is it possible in Adobe Acrobat only (not LiveCycle) to create text fields/boxes which automatically expand with their text? Scrollbars are not what we're looking for; the box itself must expand so that all the text is printable, as well as be saveable, printable and accessible.
Thank you.
Adobe Propaganda would say, this is not possible, and you will need XFA/LiveCycle Designer to do it.
It is possible, and I had it in practical use in some forms (not anymore, because they completely changed their forms system). It is "a little bit messy", and it only works with growing, but not with shrinking (although there may be some more fiddling needed to make it possible).
There is another alternative, which could work, if some tolerance is given to the precision. In this alternative, we count characters and line breaks, and change the size of the field accordingly.
Finally, the cheapass solution would be setting the font size to automatic, and let it change so that the contents fits into the field.
A simple html page has FORMATTED text - not fancy - line breaks, and italic.
I want to have a button that takes this formatted text, and copies it to the clipboard, formatted (it is planned to be pasted into some LibreOffice document later).
Couldn't find how to do it.
I tried ZeroClipboard, and a suggestion to parse the text, replacing ""-s to "\r\n". That indeed does the trick for line breaks, but what about italic?... Any means to get this functionality?...
When you create an italic tag the responsible for formatting the document and showing the text properly is the browser. If you want to copy the text you should get the text already parse and render by the browser or parse yourself the text like you did with break lines. For italics when you find a ... tag you must create the adequate text. That is, text in italics, but that depends on the language you are using, but i'm sure it can be done.
OK,
Turns out that ZeroClipboard had this functionality (of rendering the HTML text upon paste), but have disabled it.
However, the version that supports it can be found at: https://github.com/botcheddevil/ZeroClipboard
Note:
You may find that in this version, creating the client, binding the flash to a component, and handling the events are rather different than the documentation of current version of ZeroClipboard (https://github.com/zeroclipboard/zeroclipboard/blob/master/docs/instructions.md
I want to, using the DocX library [https://docx.codeplex.com/], convert a .docx document to use a different font. Does anybody know how to do that? The samples projects are very spare, and the documentation is nonexistent.
I find, too, that often there are extraneous spaces in documents, and I want to iterate over all these until there are never two contiguous spaces. I can do this in a loop, I guess, replacing " " (2 spaces) with " " (1 space) until " " (2 spaces) is no longer found.
However, I also want to remove superfluous line breaks that sometimes occur when copying-and-pasting text into a document. I can do it "manually" (in Libre Office, not sure how it's done in MS Word), as I got an answer to this question:
(select "Regular Expressions" and then replace "$" (without the quotes) with a space)
...but how programmatically, with DocX?
Additionally, in some cases I want to ADD line breaks/"paragraph returns" where there are legitimate line breaks between the end of one paragraph and the start of another, but no extra line to separate them visually. According to this:
...I can add a paragraph/line break to a legitimate line break by searching for "$" and replacing that with "\n\n"
This does work, too (manually, in Libre Office); but again...how to do this with the DocX library?
It appears that not all of this is possible with the current version of the DocX library you are using. If it is not exposed in documentation, the functions might as well not exist, and you should not be using undocumented features.
There is a much more mature library available, however, called the "Open XML SDK", that can do everything you need.
The correct way to change a font, regardless of whether you are doing it with the document editor, or you are writing a program to manipulate these files, is to change the appropriate text's style attribute, or changing the definition of style in use.
You should never, ever, ever, ever directly change the font of any text. Personally, I think that the 'font type' and 'font size' menus should be removed entirely from word/libreoffice/etc, and only be accessible inside a 'change style properties' dialog; the only reason to directly apply a font is if you are actually providing an example of particular typeface under discussion!
See How to: Replace the styles parts in a word processing document (Open XML SDK) from the MSDN documentation for a description of the way that works.
To search and replace text, the applicable MSDN page is How to: Search and replace text in a document part (Open XML SDK). For specifically replacing multiple spaces with a single space, there are numerous results on Google that should all work to at least some degree.
Using iReport 4.5.0, I'm setting these two properties and values:
net.sf.jasperreports.text.truncate.at.char=true
net.sf.jasperreports.text.truncate.suffix=...
The intent is to add "..." to the end of textfields whenever they must be truncated, and that the truncation determination happens at the character level, rather than at the word level. This works as expected when exporting to PDF. However, when exporting to HTML, the last truncated token (with the suffix appended) will often, though not always, wrap incorrectly. (It does this even though StretchType is set to No Stretch.) Example:
If I change net.sf.jasperreports.text.truncate.at.char=false (so that it breaks on words instead of characters) it seems to work more often, but only because word breaks usually leave more space for the suffix. The unexpected line wrapping still occurs with word breaks, especially if I increase the length of the given suffix.
My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all).
Can anyone confirm?
Any suggestions as to a workaround?
It seems like with StretchType set to No Stretch, that the HTML exporter should probably also set white-space:nowrap. However, although that would prevent the line from wrapping, the end of the suffix would be partially hidden (due to overflow:hidden styling).
"My best guess is that the HTML exporter measurement isn't precisely calculating the width required by the given suffix (if it's calculating it at all)."
I confirm that this is surely the reason.
But there's not really a simple workaround. Your PDF is good, so you're doing something right. Well... you're doing lots of things right. ;-)
In HTML you don't know--in a very fundamental way--the precise details of the font that will render the text. You can certainly specify the font. But the client machine might not have it. Or it might have one that is the same... but not quite the same. Or the client might choose to use a different font or different size via various client-side override mechanisms.
If you try different fonts, you should notice slightly different results. You may be able to find one that works better more often. (Clearly, this isn't 100% perfect.)
If you aren't using Font Extensions, then you should. If you are using Font Extensions, then you can specify the list of fonts in descending preference that ought to be used in the HTML. This should give you enough control to get behavior that is good in a large number of cases. Often you can make it perfect in all of the cases that you care about.
I am building a dynamic reporting feature for a client. They want to create new stored procedures, and have them correspond to new reports. We are using T-SQL and each cell in a grid/report can have its own formatting and/or functionality.
I'm looking for a format specification to identify presentation, color and conditionals for data... for instance, I am thinking of something like this:
{data}|{format}
123.56|$#,##0.00
Results in ... $123.56
I am looking for standard ways to represent the formatting field, with the potential for colors and conditionals. Is there some standard out there already?
It all depends on what you're looking for. You have to ask yourself what types of formatting you wish to apply. Here's some cases you might want to consider:
In-line formatting
Do you want to have a cell that contains mixed formatting (e.g. "1234.567" shows bold, regular and italic in a single cell)?
Multi-column based output
Do you want to output a value in a cell that's based on multiple cells?
Cell1="1234"
Cell2="56"
Cell3={Cell1}.{Cell2}
---> which would output "1234.56"
If don't need either of those things, then all you want to do is provide a single format for the entire cell. Let's divide it into the two formatting elements: transformations and visual effects:
Formatting "1234.5678" into "1234.56" is a transformation. It has to be done by code that knows how to interpret the value as a number, and how to turn that number into the textual string of digit-characters.
Making a cell blue, or the text red, or bold - these are all visual transformations that are merely a set of attributes regarding the display of data in a cell. We don't care here about the type of data in the cell, since we just have to put pixels on a screen.
So, to bottom-line this: it's all about what you want to happen. If you're producing HTML reports, then HTML & CSS are very convenient methods for describing the visual-effects formatting of the cell, since you won't have to convert it twice.
As far as I know, there's only a couple of standards for encoding visual-effects display, and they are similar to SGML - TeX, HTML, PostScript, etc; they all have "tags" (sometimes with "attributes") to modify the display of the content within the tag.
Which leaves us the transformational formatting. There were two common approaches to this. The first is procedural. You list a set of transformations you wish to do on the data to turn it into text. Nowadays, we often use substitution masks, like in your example, $#,##0.00, or like in sprintf's %.2f, etc.
Again, just choose a formatting specifier that is the simplest to use in your environment. If you're coding in a language that accepts a certain format, then use it!