I'm facing a problem while trying to generate a PdfPTable and calculate its height before adding it to a document. The method calculateHeights of PdfPTable returned the height a lot greater than the height of a page (while the table is about 1/4 of page's height), so I wrote a method to calculate the height:
protected Float getVerticalSize() throws DocumentException, ParseException, IOException {
float overallHeight=0.0f;
for(PdfPRow curRow : this.getPdfObject().getRows()) {
float maxHeight = 0.0f;
for(PdfPCell curCell : curRow.getCells()) {
if(curCell.getHeight()>maxHeight) maxHeight=curCell.getHeight();
}
overallHeight+=maxHeight;
}
return overallHeight;
}
where getPdfObject method returns a PdfPTable object.
Using debugger I've discovered that lly and ury coordinate difference (and thus the height) of cell's rectangle is much bigger than it looks after adding a table to a document (for example, one cell is 20 and the other is 38 height while they look like the same on a page). There is nothing in the cell except a paragraph with a chunk in it:
Font f = getFont();
if (f != null) {
int[] color = getTextColor();
if(color != null) f.setColor(color[0],color[1],color[2]);
ch = new Chunk(celltext, f);
par = new Paragraph(ch);
}
cell = new PdfPCell(par);
cell.setHorizontalAlignment(getHorizontalTextAlignment());
cell.setVerticalAlignment(getVerticalTextAlignment());
A table then has a cell added and setWidthPercentage attribute set to a some float.
What am I doing wrong? Why does cell's proportions are different from those I see after generating PDF? Maybe I'm calculating the height wrong? Isn't it the height of a cell on a PDF page should strictly be the difference between lly and ury coordinates
Sorry I haven't shown the exact code, because the PDF is being generated of XML using lots of intermediate steps and objects and it is not very useful "as is" I guess...
Thanks in advance!
The height of table added to a page where the available width is 400 is different from the height of a table added to a page where the available width is 1000. There is no way you can measure the height correctly until the width is defined.
Defining the width can be done by adding the table to the document. Once the table is rendered, the total height is known.
If you want to know the height in advance, you need to define the width in advance. For instance by using:
table.setTotalWidth(400);
table.setLockedWidth(true);
This is explained in the TableHeight example. In table_height.pdf, you see that iText returns a height of 0 before adding a table and a height of 48 after adding the table. iText initially returns 0 because there is no way to determine the actual height.
We then take the same table and we define a total width of 50 (which is much smaller than the original 80% of the available width on the page). Now when we calculate the height of the table with the same contents, iText returns 192 instead of 48. When you look at the table on the page, the cause of the difference in height is obvious.
Inorder to get dynamic table height we should set and lock width of table.
Here, 595 is A4 size paper width.
table.setTotalWidth(595);
table.setLockedWidth(true);
Related
I use a Label with text wrap enabled. In this case, the text wraps wrong. The text wraps into 3 lines, when it should be only 2 and the Label size only reflects the 2 lines. I debugged through the code and found the reason for this to be in the Label.layout() method. Not sure if this is a bug or if I am doing something wrong.
In the code below you can see that the text is set twice to the GlyphLayout. The first time it wraps correct, the second time we use the reduced width and it wraps into more lines as before. I think the second time we set the text into the GlyphLayout, the same width should be used.
public class Label extends Widget {
public void layout () {
...
float width = getWidth(), height = getHeight();
...
GlyphLayout layout = this.layout;
float textWidth, textHeight;
if (wrap || text.indexOf("\n") != -1) {
// Set the text into the GlyphLayout. The text is wrapped correctly here
layout.setText(font, text, 0, text.length, Color.WHITE, width, lineAlign, wrap, ellipsis);
textWidth = layout.width;
textHeight = layout.height;
...
} else {
textWidth = width;
textHeight = font.getData().capHeight;
}
...
// Set the text again into the GlyphLayout. This time with the width that we got when we set it the first time
// This time the text is wrapped wrong as it uses less width as it should
layout.setText(font, text, 0, text.length, Color.WHITE, textWidth, lineAlign, wrap, ellipsis);
...
}
}
Make sure to invalidate() the label and then pack() the label so it calculates any new preferred sizes; this may or may not fix the problem.
Looking at the source code of Label then you can see that the last invocation of layout.setText() is always invoked regardless of text wrapping or not.
The previous layout.setText() invocation is used to set the textWidth and textHeight for the later call where those values are actually used.
If wrapping is on or there is a newline character then the width and height is set to that of the label and if it is off then the width is set to the actual text width and the height set to the font data height.
From the above, another problem that may be causing this to happen is if you have scaled the font and/or label. The scaling factor is not being applied from within Label.layout() which may cause the label size to be that of 2 lines whilst the actual text is 3 lines as the width doesn't allow for overflow with wrapping set to on.
If all else fails, I would ensure that your font files are correct and that there are not any characters or data in your text that may cause a new line to occur.
I would also suggest to use another font of the same glyph width and height and see if the problem persists. If it does not then at least you know it is a problem relating to the font and not the label.
Hope this helped you.
This issue has been solved in libgdx 1.9.12
We are planning to migrate our pdf generation utilities from iText to PDFBox (Due to licensing issues in iText). With some effort, I was able to write and position text, draw lines etc. But creating Tables with text embedded in Table cells is a challenge, I went through the documentation, examples, Google, Stackoverflow couldn't find a thing. Was wondering if PDFBox provides native support for creating Tables with embedded text. My last resort would be to use this link https://github.com/eduardohl/Paginated-PDFBox-Table-Sample
Since I also needed table drawing functionality for a side project, I implemented a small "table drawer" library myself, which I uploaded to github.
In order to produce such a table – for instance – ...
... you would need this code.
In the same file you find the code for that table as well:
The current "feature list" includes:
set font and font size on table level as well as on cell level
define single cells with bottom-, top-, left- and right-border width separately
define the background color on row or cell level
define padding (top, bottom, left, right) on cell level
define border color (on table, row or cell level)
specify text alignment (vertical and horizontal)
cell spanning and row spanning
text wrapping and line spacing
Also it should not be too hard to add missing stuff like having different border colors for borders on top, bottom, left and right-borders, if needed.
Thanks to the links provided by Tilman. Using the boxable API (https://github.com/dhorions/boxable) I was able to create the table I wanted to. Just an FYI I wanted to create the table with variable number of cells. For example row 1 would have 2 cells, row 2 could have 5 cells and row 3 could have just 3 cells. I was able to do with ease. I followed Example1.java in the link mentioned above.
This example code works for me. I think this would be helpful to you
public static void creteTablePdf() throws IOException {
PDDocument document = new PDDocument();
PDPage page = new PDPage();
document.addPage(page);
int pageWidth = (int)page.getTrimBox().getWidth(); //get width of the page
int pageHeight = (int)page.getTrimBox().getHeight(); //get height of the page
PDPageContentStream contentStream = new PDPageContentStream(document,page);
contentStream.setStrokingColor(Color.DARK_GRAY);
contentStream.setLineWidth(1);
int initX = 50;
int initY = pageHeight-50;
int cellHeight = 20;
int cellWidth = 100;
int colCount = 3;
int rowCount = 3;
for(int i = 1; i<=rowCount;i++){
for(int j = 1; j<=colCount;j++){
if(j == 2){
contentStream.addRect(initX,initY,cellWidth+30,-cellHeight);
contentStream.beginText();
contentStream.newLineAtOffset(initX+30,initY-cellHeight+10);
contentStream.setFont(PDType1Font.TIMES_ROMAN,10);
contentStream.showText("Dinuka");
contentStream.endText();
initX+=cellWidth+30;
}else{
contentStream.addRect(initX,initY,cellWidth,-cellHeight);
contentStream.beginText();
contentStream.newLineAtOffset(initX+10,initY-cellHeight+10);
contentStream.setFont(PDType1Font.TIMES_ROMAN,10);
contentStream.showText("Dinuka");
contentStream.endText();
initX+=cellWidth;
}
}
initX = 50;
initY -=cellHeight;
}
contentStream.stroke();
contentStream.close();
document.save("C:\\table.pdf");
document.close();
System.out.println("table pdf created");
}
Would it be possible to get the width of a string based on its font?
So for example, if the font size is 40, and the string was "hi", could you do 2*40.
An example of this would be
startX = 260; startWidth = "Start".length()*getFont().getSize();
startY = getHeight()-startWidth-20;
startHeight = getFont().getSize();
It really depends on the type of font, whether it's monospaced or proportional. Most font now are proportional so you would not simply be able to calculate num_of_chars * n.
The gui interface you are using should give you the width of the container once it has been populated with the given text.
There is a method in PDFBox's font class, PDFont, named getFontHeight which sounds simple enough. However I don't quite understand the documentation and what the parameters stand for.
getFontHeight
This will get the font width for a character.
Parameters:
c - The character code to get the width for.
offset - The offset into the array. length
The length of the data.
Returns: The width is in 1000 unit of text space, ie 333 or 777
Is this method the right one to use to get the height of a character in PDFBox and if so how? Is it some kind of relationship between font height and font size I can use instead?
I believe the answer marked right requires some additional clarification. There are no "error" per font for getHeight() and hence I believe it is not a good practice manually guessing the coefficient for each new font.
Guess it could be nice for your purposes simply use CapHeight instead of Height.
float height = ( font.getFontDescriptor().getCapHeight()) / 1000 * fontSize;
That will return the value similar to what you are trying to get by correcting the Height with 0.865 for Helvetica. But it will be universal for any font.
PDFBox docs do not explain too much what is it. But you can look at the image in the wikipedia Cap_height article to understand better how it is working and choose the parameter fit to your particular task.
https://en.wikipedia.org/wiki/Cap_height
EDIT: Cap height was what I was looking for. See the accepted answer.
After digging through the source of PDFBox I found that this should do the trick of calculating the font height.
int fontSize = 14;
PDFont font = PDType1Font.HELVETICA;
font.getFontDescriptor().getFontBoundingBox().getHeight() / 1000 * fontSize
The method isn't perfect though. If you draw a rectangle with the height 200 and a Y with the font size 200 you get the font height 231.2 calculated with the above method even though it actually is printed smaller then the rectangle.
Every font has a different error but with helvetica it is close to 13.5 precent too much independently of font size. Therefore, to get the right font height for helvetica this works...
font.getFontDescriptor().getFontBoundingBox().getHeight() / 1000 * fontSize * 0.865
Maybe use this?
http://pdfbox.apache.org/apidocs/org/apache/pdfbox/util/TextPosition.html
Seems like a wrap-around util for text. I haven't looked in the source if it accounts for font error though.
this is a working method for splitting the text and finding the height
public float heightForWidth(float width) throws IOException {
float height = 0;
String[] split = getTxt().split("(?<=\\W)");
int[] possibleWrapPoints = new int[split.length];
possibleWrapPoints[0] = split[0].length();
for (int i = 1; i < split.length; i++) {
possibleWrapPoints[i] = possibleWrapPoints[i - 1] + split[i].length();
}
float leading = font.getFontDescriptor().getFontBoundingBox().getHeight() / 1000 * fontSize;
int start = 0;
int end = 0;
for (int i : possibleWrapPoints) {
float w = font.getStringWidth(getTxt().substring(start, i)) / 1000 * fontSize;
if (start < end && w > width) {
height += leading;
start = end;
}
end = i;
}
height += leading;
return height + 3;
}
For imported True Type Fonts the total height of the font is
(org.apache.pdfbox.pdmodel.font.PDFont.getFontDescriptor().getDescent() + org.apache.pdfbox.pdmodel.font.PDFont.getFontDescriptor().getAscent() + org.apache.pdfbox.pdmodel.font.PDFont.getFontDescriptor().getLeading()) * point size * org.apache.pdfbox.pdmodel.font.PDFont.getFontMatrix().getValue(0, 0)
You will find that font.getFontDescriptor().getFontBoundingBox().getHeight() is 20% larger than the above value as it includes a 20% leading on the above value, but if you take the top value and remove 20%, the font will be right next too each other
I have a Java Swing application that i want to create a nice component in it like a component in Microsoft word. In Microsoft word you can change the margins of your document like in here :
The trick here is that if you change the Top margins to (Let's say) 1.5" then the Preview image will change to show this, so the lines will move down a bit in the image to show that change in the margins so the user can feel how much his document will be affected by this change. So for example if i change the left margin to (4.0") the image will look like this :
What i did is create 2 images a blank page image + another image that contains lines only(Lines image), like these 2 images :
I inserted each image in a JLabel above each other, and now when i change the JSpinner top margin value, i keep the "blank page" image fixed, but i change the border of the "lines image" to move it down a bit. The trick worked fine for the top margin, but the behavior goes totally wrong if i change the bottom/right/left margins.
Here is my code that i apply when changing any JSpinner value :
private void marginSpinnerStateChanged() {
//1. Get the approximate values of all margins :
int topMargin = (int)( Float.valueOf( topSpinner.getValue().toString() ) * 8 );
int bottomMargin = (int)( Float.valueOf( bottomSpinner.getValue().toString() ) * 8 );
int leftMargin = (int)( Float.valueOf( leftSpinner.getValue().toString() ) * 8 );
int rightMargin = (int)( Float.valueOf( rightSpinner.getValue().toString() ) * 8 );
//2. Apply all specified margins to the lines label :
linesLabel.setBorder( new EmptyBorder( topMargin, leftMargin, bottomMargin, rightMargin ) );
}
Can you help me continue this to work right ?
You could just draw the image on top of the paper and scale the image as you go. So you would override the paintComponent() method of a JComponent to do something like:
g.drawImage(image, x, y, width, height, null);
x - would be the left margin
y - would be the top margin
width - would be (maxWidth - leftMargin - rightMargin)
height - would be (maxHeight - topMargin - bottomMargin)
If you don't like scaling the image you can always use a BufferedImage and then use the getSubImage(...) method to get an image the desired size to be painted.
If you notice, they don't shift the textual image. Instead, they only show half of it. This is simple image manipulation. For a good example, see this.