i am currently trying to convert XHTML to Docx with Docx4j.
I figured everything out but the table-row-height or the spacing of it is not ok - it always get spacing after the text. At the moment this also only happens for the first line so this is really strange
We tried to set the trHeight globally but it did not work as we wanted.
Has anyone got an Idea what to do (maybe in HTML / CSS) or what can cause this Problems of to much space between?
Related
I have a Html file which is roughly 4.3MB contains a table with 6 columns and 10k rows. Each cell contains 1-10 characters, has only "class" attribute for its style which is very simple (font family, font size, text color and cell color).
I converted this file to Pdf but EvoPdf used almost 11GB RAM (I built my project to run on 64bit) and crashed my IIS but didn't return any result. I tried with fewer row (5k) and EvoPdf did return result but still use a lot memory. And the result is almost 150MB.
I don't know I did anything wrong there.
And for my settings, I use repeat table header and embed font.
Can someone help me?
Thank you.
We have uploaded a file with bad encoding now when downloading it again all the "strange" French characters are mixed up.
Example of the bad text:
R�union
Now when opening the CSV with Openoffice we tried all of the encodings in the Dropdown none of them seem to work.
Anyone have a way to fix the encoding to the correct one that we can view the chars?
Links to file https://drive.google.com/file/d/0BwgeuQK3LAFRWkJuNHd2TlF2WjQ/view?usp=sharing
Kr.
Sadly there is no way to automatically fix the linked file. Consider the two words afectación and sécurité. In the file they have been converted incorrectly to afectaci?n and s?curit?. There is no way to convert the question marks back because sometimes they're ó and other times é.
(Actually instead of question marks the file uses the unicode replacement character, but that doesn't change the problem).
Hopefully you have an earlier version of the file that has not been converted incorrectly.
Next time try to use a consistent encoding. This question gives some suggestions for how to do this.
If the original data cannot be obtained, there is one thing that could be done outside of retyping the whole thing. It is possible to use dictionary lookups to guess the missing words. However this would be a difficult project, and there would be mistakes where incorrect guesses were made. It's probably not worth it.
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?
I am new to fop , will be greatful if i get help from someone...,
I am not using XSLT tranformation but creating XSLFO file directly using Java code. Everything works fine but the problem comes when particular word(long text without space) is inserted into a cell of a table-column . That bigger word is overlapping the successive block.
I have an fo:block element in fo:table-cell which is in fo:table-row of a fo:table. This table has 6 columns, obviously column width is small. Now, when a Word in the block is larger than the block it is overlapping the next block. Give me some attribute value or any other solution to change my XSLFO file ,so that the bigger word breaks into the new line at end of the column.
Thanks in advance...
The things you need to look into are:
For the fo:table-cell: number-columns-spanned="3"
For setting the width of fo:table-column: column-width="proportional-column-width(1.5)"
The number-columns-spanned is used as attribute of and provides you with a means to select a bigger area where your fo:block fits.
The column-width makes it easy to define absolute width or, when using proportional-column-width, a width relative to the other columns.
I don't know of a way that lets FOP break words into multiple parts when they don't fit.
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.