I have Windows Forms VB.NET application developed under VS2005. I am using Crystal Reports for Visual Studio 2005. The reports has some Arabic and Hebrew text in it. My problem is that although text appears correct in the viewer at run time, when exported to any format including PDF the text appears reversed. The letters appear correctly but the arrangement of the letters in words is reversed and accordingly the word appear incorrectly.
Is there a way to fix this.
Thanks
The problem was fixed by selecting text object paragraph right-to-left property.
Related
I am trying to extract text from PDF using iTextSharp but I get null reference error while trying to call GetTextFromPage:
My guess would be that iTextSharp somehow interprets page label incorrectly as it is indeed strange:
Or is it due danish letters in the text?
However, I am able to extract text from different languages.
Thank you in advance.
EDIT: The problem could also be used fonts and their custom encoding:
I have this PDF ebook with selectable text - the handwriting - but there is no such font embedded and the letters are all different, so it's not actually a font. How is this possible?
I've worked with CorelDraw and Adobe Acrobat, but I can't understand how this works.
The left side of the picture shows the document properties, the right side shows a page of the PDF file and I selected the last 3 rows. I can copy and paste that to a text file, no problem. How was this achieved?
There are a few possibilities but the most likely is the text is being converted to outlines/paths or vectors. Some software such as Adobe InDesign and other print design apps allow you to 'flatten' a font based text into vector or paths, meaning the original font isn't required to be embedded or installed on the system. The original text data is however still present and able to be copied into a text field or word processor.
I have a set of reports created with SQL Server Business Intelligence Studio 2008.
Reports run on SSRS 2008 and exported to PDF.
In PDF files, however, some of the text cannot be found by "Find". If this text is copied from PDF and pasted into a text document, a strange combination of symbols is pasted - i.e. Copy "1400" from PDF and "1e4d0it0e" is pasted, see screenshot below.
Another strange feature: the same field, in this case "Id", is presented in two tables in the same report, and in the first case some Ids are "garbled" in PDF, but in the second all are rendered correctly. I can see no visible differences between tables.
Any ideas on how to prevent such behaviour?
I found why this is happening, even though it makes no sense to me.
Where the text is displayed properly in the PDF, the textbox has a setting CanGrow=true.
Where the text is "garbled" in PDF after Copy-Paste, the textbox has a setting CanGrow=false.
Changing the setting on the textbox fixes the issue.
I have created a basic RDLC report in Visual Studio 2010. In the report designer it looks fine, and when I use the report viewer to view the report it also looks fine. However, once I send the report to a printer, there seems to be an issue with the kerning or tracking, such that there are no spaces between characters, and all the letters are somewhat wider than they should be. Has anyone come across this before and if so, do you know how to fix it?
I'm trying to build a web app to programmatically fill out a PDF form. I am going to configure my form first in Adobe Acrobat, then write a Java app with iText to fill out all the form fields via user input from the web. The base form I need to fill out comes from the US government. They created form fields with extremely large kerning (character spacing) values I need to change. However, there appears to be no way to modify this value in the Acrobat UI.
Does anyone know how to manipulate character spacing on form fields in Acrobat 8.0 for Windows? I could try to use iText to programmatically manipulate the kerning of the original document, but this would be much more tedious.
I believe I figured this out: kerning is called "combing" in acrobat, and each of the form fields have been "combed". The strange thing is this option isn't checked when I view the properties of the form field, but "combing" is the behaviour I was attempting to replicate.