I'm using iTextSharp to fill in some stamper AcroFields.
stamper.AcroFields.SetField("Title", "Lipsum");
I created the pdf in illustrator and the form fields with Adobe Acrobat X Pro. The problem is that although the text fields are the width of the page, in the saved pdf the text wraps at about 1 third of the width.
Another question would be if it's possible the have the textfield autoSize in height, or a way to handle the overflow of the text.
1) I'd like to see that PDF. I suspect the fields aren't as wide as you think they are.
2) You can set a field's font size to zero to enable "auto sizing", which works both within Reader and iText. However, it sizes to the actual field size, not what you think it might be.
I'm guessing you drew a spiffy form field background in Illustrator, then put a field over it in Acrobat Pro, but didn't size the field width to match the spiffy illustrator background. Could be wrong, but that's my hunch.
That's the flattened PDF. Can I see the original with the form field still intact? Sorry I wasn't more specific. None the less, I can learn a little from reading this PDF:
Looking at the bounding boxes for the flattened field XObject and it's internal clipping rectangle, it looks like it should be using most of the page:
The page is ~600 points wide by ~850 tall.
The flattened field XObject is ~560 points wide by ~100 tall.
I wonder if there's some non-standard carriage return characters in your text that iText picks up on by Acrobat does not...
Anyway, I'd like to see the unflattened PDF. Filled in is good, but not flattened.
Okay, looked at the template. I don't see anything that would cause the line breaking you're seeing... which makes me think my second guess was right: new line characters.
Looking at the text layout code might give me a hint. Each of your lines of text goes like this (for example):
1 0 0 1 2 88.24 Tm 0 g (Die Semmerrolle der l{e4}nge nach zu einer grossen Roulade)Tj
n n n n n n Tm: text matrix
g: gray (0 g: black)
(...)Tj: show text
That's consistent with the code path when you set a text field value in the trunk of iText (and the most recent release[s]). That code (ColumnText) is quite good at breaking text properly, and used all over the place. The bounding box is correct (as shown in a couple places of the flattened PDF).
Check your input.
Related
I generated a table with iText7 (C#):
var cell = new Cell().Add(new Paragraph(headers[c]).SetFont(font).SetFontColor(ColorConstants.WHITE).SetFontSize(size).SetBold());
cell.SetBackgroundColor(color);
cell.SetTextAlignment(iText.Layout.Properties.TextAlignment.CENTER);
cell.SetPadding(0);
cell.SetBorder(new SolidBorder(1));
table.AddCell(cell);
Document has the table, but on certain scalings, it looks weird on the edges:
Taking a closer look on the image above:
If however I change the zoom in the viewer directly, it looks OK:
How do I get rid of these unnecessary parts from the border?
I'm attaching here the resulted PDF for reference:
Download sample PDF
I also noticed that on iText KB pages, there is this kind of behavior:
https://kb.itextpdf.com/home/it7kb/faq/how-do-i-change-the-border-color-of-a-pdfpcell
See the red and blue bars' left edges:
This behaviour is not uncommon in PDF or other print drivers where vectors are printed rather than plotter definitions (often called "Dangles". It would be worse if the definition was rounded or square, rather than butt, and join as "mitre" cannot apply, see below). The overlap is intentional (to ensure both lines are inclusive). In a laser drum print that may be desirable overkill, but disastrous for any inkjet or screen. It looks like the cell is not bordered by a box, but using common straight vectors. Again this is often desirable optimisation but not when the weight is not honoured. Thus it depends if the viewer is using the correct thickness.
All desktop PDF viewers (icluding Chrome and FireFox) I tested showed the lines correctly as clean overlap without "Dangles". Acrobat has a reputation for undesirably thickening or thinning its standard defined lines depending on its user settings.
The Problem
I am loading the classic serife.fon file from Microsoft Windows using FreeType.
Here is how I set the size:
FT_Set_Pixel_Sizes(face, 0, fontHeight);
I use 0 for the fontWidth so that it will be auto-calculated based on the height.
How do I find the correct value for fontHeight such that the resulting font will be exactly 9 pixels tall?
Notes
Using trial and error, I know that the correct value is 32 - but I don't understand why.
I am not sure how relevant this is for bitmap fonts, but according to the docs:
pixel_size = point_size * resolution / 72
Substituting in the values:
point_size = 32
resolution = 96 (from FT_Get_WinFNT_Header)
gives:
pixel_size = 42.6666666
This is a long way from our target height of 9!
The docs do go on to say:
pixel_size computed in the above formula does not directly relate to the size of characters on the screen. It simply is the size of the EM square if it was to be displayed. Each font designer is free to place its glyphs as it pleases him within the square.
But again, I am not sure if this is relevant for bitmap fonts.
fon files are exe files with a fnt payload, where the fnt payload can be a vector or raster font. If this is a raster font (which is most likely) then the dfPixHeight value in the fnt header will tell you what size it's meant to be, which is exposed by FreeType2 as the pixel_height field of the FT_WinFNT_Header.
(And of course, note that using any size other than "the actual raster-size of the FNT" is going to lead to hilarious headaches because bitmap scaling is the kind of madness that's so bad, OpenType instead went with "just embed as many bitmaps as you need, at however many sizes you need, because that's the only way your bitmaps are going to look good")
The FNT-specific FT2 documentation can be found over on https://www.freetype.org/freetype2/docs/reference/ft2-winfnt_fonts.html but you may need to read it in conjunction with https://jeffpar.github.io/kbarchive/kb/065/Q65123 (or https://web.archive.org/web/20120215123301/http://support.microsoft.com/kb/65123) to find any further mappings that you might need between names/fields as defined in the FNT spec and FT2's naming conventions.
I use simple GDI DrawText to output blocks of text to a printer.
The font used in the sample is Segoe UI. But you can use Arial or others too. It doesn't matter.
The algorithm for large text blocks is simple. DrawText is called with DT_CALCRECT with a kind of binary search for the length to get the largest possible text to print. Than DrawText is called without DT_CALCRECT to print the block.
Simple one line text column text is written with one call to DrawText with the given coordinates of the rectangle.
The result is real strange and can be seen in this sample PDF.
Just look on the first line after the header. You can see the text "Test, Test" and you can see the strange kerning here perfectly. The kerning os sometimes so bad, that you can't even read the words.
How to get around this? Is it a problem with the used printer? Is it a problem with DrawText?
The distance between some chars in a word seem to be random in some case. Some spacing are wide other to narrow. The letter combination looks strange unreadable and ugly.
I tried different fonts and printers but the problem just varies but it is always present.
I know about ExTextOut and the capabilities to define the distance/kerning between all chars, but frankly I don't want to care about this. I just want that DrawText behaves on the printer like on the screen. The stuff works on the screen perfectly.
Added 2018-08-23 08:49 GMT+2*
To the code (it is a complex printing engine).
1.Fonts to print are created simply with CFont::CreatePointFont, so the LOGFONT structure is cleared to zero and no additional flags are used except point and face.
2.The mapping mode is MM_ANISOTROPIC. To scale what is seen on the screen and what is to be printed I just use the size of a komparable object (textblock) on the printer and the same size on the screen. The real values for the sample printout to the Microsoft PDF Printer are as follows, the real way I calculate them is not of interest:
m_pDC->SetMapMode(MM_ANISOTROPIC);
m_pDC->SetViewportExt(2363,100);
m_pDC->SetWindowExt(355,13);
This has the effect that the height of a line in LPs is 13, the average character width in LPs is 6...
If I have the axis label $x_\textrm{ABC}$, the ABC is way too big. I tried $x_\textrm{\scriptsize ABC}$ and $x_\textrm{\tiny ABC}$, but that prevents the LaTeX code from being interpretted (I end up seeing the raw code instead of the formatted math). How does one shrink the subscript text size when the subscript is a name that needs to be spelled in text mode?
I posted this to usenet yesterday, but no response so far.
I also tried to modify the text in Acrobat Pro, but I can't actually highlight the individual series of characters (it's the y-axis label).
Finally, I tried to modify it in inkscape, but same problem.
A respondent at the usenet link provided the answer: To use \mathrm instead of \textrm. It looks way better.
I am creating a GUI containing an image using the following code:
try
Imagenamehere = imread('Imagenamehere.jpg');
axes(handles.Logo)
image(Imagenamehere)
set(gca,'xtick',[],'ytick',[])
catch
msgbox('Please download all contents from the zipped file into working directory.')
end
The image shows up but for some reason is completely coloured blue as if put through a blue filter. I don't think it would be wise to upload the image but it is a simple logo coloured black and white.
Anyone know what could be causing this?
Check the size, type (probably uint8) and range of your image. It sounds like for some reason your images are being displayed with colormap as jet (the default), and possibly also that your range is not what MATLAB expects (e.g. 0 to 1 not 0 to 255), resulting in all your values being relatively low (blue on the jet colormap).
"black and white" is just one way of interpreting an image file which contains only two colors. MATLAB makes several assumptions when you pass data into a display function like image. If you don't specify colormap and image data range, it will make a guess based off things like data type.
One possibility is that your logo file is an indexed image. In these cases you need to do:
[Imagenamehere map] = imread('Imagenamehere.jpg');
colormap(map);