Major Font Bug (For my use anyway)

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   After nearly a week of intensive testing I am almost certain of the following:

When using a zero width character (floating accents) the program outputs
() Tj

but if I give the same character a width the program outputs
(n)Tj

Is this problem easily corrected or do I have to abandon the program?

(This is a followup of my question about TrueType fonts - in the above example I created two Type 1 fonts both in the range 32 to 125 from the orriginal TrueType Font and renamed all the characters to be normal ansi characters)

Bob

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
HolmeBob Members Profile Find Members Posts Beginner Joined: 05 Feb 07 Location: United Kingdom Status: Offline Points: 5	Post Options Post Reply Quote HolmeBob Report Post Thanks(0) Quote Reply Topic: Major Font Bug (For my use anyway) Posted: 13 Feb 07 at 5:23AM
	After nearly a week of intensive testing I am almost certain of the following: When using a zero width character (floating accents) the program outputs () Tj but if I give the same character a width the program outputs (n)Tj Is this problem easily corrected or do I have to abandon the program? (This is a followup of my question about TrueType fonts - in the above example I created two Type 1 fonts both in the range 32 to 125 from the orriginal TrueType Font and renamed all the characters to be normal ansi characters) Bob

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply Posted: 13 Feb 07 at 5:29AM
	Bob, for support please provide sample source code (VB, VB.NET, VBS, JScript, Delphi, C#, C++). Send your sample to support(at)quickpdf.org and I will test your problem. Best regards, Marian

HolmeBob Members Profile Find Members Posts Beginner Joined: 05 Feb 07 Location: United Kingdom Status: Offline Points: 5	Post Options Post Reply Quote HolmeBob Report Post Thanks(0) Quote Reply Posted: 13 Feb 07 at 11:48AM
	Hi Marian, My Boss gave me a clue this morning - He reckons that QuickPDF is looking at the width of a character and decides that if it has no width then it is not valid. The problem is font independent i.e. same problem for TrueType & Type1 Fonts, it is also character position independent - no width no character. If I give the characters a 1 unit width then the characters are output correctly. The code is very simple: c = "n" cv = asc(c) SELECT CASE ctabv CASE 1 iSEDSelectFont(font1) pdferror = iSEDSetFontEncoding(2) CASE 2 iSEDSelectFont(font2) pdferror = iSEDSetFontEncoding(2) END SELECT ztemptext = CHR$(ctab(cv,2)) iSEDAppendText(ztemptext) Edited by HolmeBob - 13 Feb 07 at 11:51AM

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply Posted: 14 Feb 07 at 5:50AM
	Bob, I may understand why this situation occur. There is a check for input text which removes any character identified as "non printable". Well, I have not so much time to research the theory for your problem. Do you want to suggest a CR on this feature? To me it makes no sense what happens inside QuickPDF library but I don't want to change functionality just because of my opinion. We (I) need a proper statement to justify a CR and if you find a valid one inside PDF specification your CR is like accepted. Best regards, Marian

HolmeBob Members Profile Find Members Posts Beginner Joined: 05 Feb 07 Location: United Kingdom Status: Offline Points: 5	Post Options Post Reply Quote HolmeBob Report Post Thanks(0) Quote Reply Posted: 14 Feb 07 at 12:06PM
	Marian, You seem to have a lot on your plate so we will let the matter drop as I don't think many people use floating accents these days and they are rather tricky to implement in QuikPDF. Giving a floating accent a 1 unit width is an acceptable work arround. Many thanks for your prompt replies to this query. Bob

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply Posted: 14 Feb 07 at 12:30PM
	Bob, for development your issue is a small one. The only thing which I really need is knowledge of PDF specification. I don't want to invest on theoretical meters, that's why I need your suggestion. In your case I cannot make a direct change in the public release but I may open a door for you in case that you own a source code license. In that case I would have added a conditional define for not scanning the width of the text characters, define which is disabled (check with enable) by default. You could use that define to disable this check and have your own custom solution. And by the way, the proper way to write Regional dependent text is with the usage of Unicode Characters. But here I have no experience and for more information you should ask somebody else.

HolmeBob Members Profile Find Members Posts Beginner Joined: 05 Feb 07 Location: United Kingdom Status: Offline Points: 5	Post Options Post Reply Quote HolmeBob Report Post Thanks(0) Quote Reply Posted: 16 Feb 07 at 4:58AM
	Marian, I am afraid that I have no knowledge of the PDF specification however I do know that we have been producing PDF's with floating accents since PDF's became available via PhotoTypesetting Programs and the Distiller. I would be very surprised if the PDF specification prohibited zero width characters - certainly the Distiller doesn't care. I really think that this was an erroneous QuickPDF decision. At the moment I am running an evaluation version of the program to learn if it will do what I want so I have a lot to learn. Having solved the major problem things are looking good sofar. I would not be buying the source code as I have no Delphi experience. You are right about using Unicode but the Unicode specification is not yet complete. Our current font took over 15 years to develop (240 Glyphs - I shudder to think how long it would take to develop a Unicode Font of nearly 1000 Glyphs) so I don't think we will make any changes. As I said, unless someone else has the same problem and is not prepared to use my work arround, we can consider the subject closed. Many thanks, Bob

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply Posted: 16 Feb 07 at 6:49AM
	Bob, if is not too much to ask maybe you can send us a copy of a small PDF document with such "floating accents", first generated with Acrobate Distiler and second with QuickPDF. If the result is correct for Distiler I will apply the same algorithm as there (please name your files after the engine used in PDF production). Maybe you can print out all 240 Glyphs to see how they have to be processed correctlly. Of course only for the case that your font is not a big secret for us. Our support email address is: support/at/quickpdf.org Best regards, Marian