I need help - I can help - Major Font Bug (For my use anyway)

Print Page | Close Window

Major Font Bug (For my use anyway)

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=640
Printed Date: 11 Jul 25 at 2:47PM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Major Font Bug (For my use anyway)

Posted By: HolmeBob
Subject: Major Font Bug (For my use anyway)
Date 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

Replies:

Posted By: marian_pascalau
Date 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

Posted By: HolmeBob
Date 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)

Posted By: marian_pascalau
Date 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

Posted By: HolmeBob
Date 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

Posted By: marian_pascalau
Date 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.

Posted By: HolmeBob
Date 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

Posted By: marian_pascalau
Date 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