[Question] How to check and add a font into DR dictionary of the interactive form dictionary (AcroForm) in the catalog dictionary? about pdf-writer HOT 39 CLOSED

Creating the Acroform object can be done using the extensibility method of the Object Context. you can read about them here - https://github.com/galkahana/PDF-Writer/wiki/The-ObjectsContext-Object

specifically you will be looking into creating a new indirect object and a dictionary inside it.
There's a sample here - http://pdfhummus.com/post/45501642143/how-to-extend-the-library-adding-comments-to - on creating new types of objects (it creates annotations there, but the principal is the same).

You will also need to add a reference to the acroform from the catalog object.
you do that by implementing a handler forOnCatalogWrite method of IDocumentContextExtender and attaching a listener prior to the pdfwriter ending.

you can read about it here:
https://github.com/galkahana/PDF-Writer/wiki/The-DocumentContext-Object#extending-document-context-level

As for the resource dictionary. A, seems like it is optional, and i think that it should remain so. this will cause acrobat or whomever to make decisions on how to implement the interactive parts in terms of fonts and such.
If you do want to create a resource dictionary and use a custom font, then you can use the ResourcesDictionary class.
to learn how to write its entry in DR, follow how Page writing does it -
https://github.com/galkahana/PDF-Writer/blob/master/PDFWriter/DocumentContext.cpp#L686

The last bit is the font, and it's a good question how to embed it. it's a bit tricky, but i'm guessing that it goes through reusing PDFWriter capabilties. You can create a PDFUsedFont for your font (in a similar manner to how you normally do it), and then add all letter through EncodeStringForShowing, like done here:
https://github.com/galkahana/PDF-Writer/blob/master/PDFWriter/AbstractContentContext.cpp#L1102

but honestly i don't think that you need this part. so skip it first and only if things dont work do it (i mean...at least see some sample PDFs with forms and see if they have it and what is written there)

Regards,
Gal.

from pdf-writer.

When i use a standard font, like Helvetica, do i still need to embed it ? and do I need to find the system font file path for loading it?

from pdf-writer.

no need to embed at all, no need to declare. the system will take care of itself.
helvetica is one of the 14 basic fonts that are expected to be available. you can embed (and with hummus, unless you use Tj operator directly, this will be the case), but you don't have to.

from pdf-writer.

How to construct a PDFUsedFont instance for the standard font to call Tf and Tj ?
i.e. contentContext->Tf(font,14) need the font object

from pdf-writer.

Good question.
When using non embedded font you can use TfLow and TjLow to provide string values directly:
https://github.com/galkahana/PDF-Writer/wiki/Text-support#low-level-text-commands

Regards,
Gal.

from pdf-writer.

contentContext->TfLow("Helvetica",14);
contentContext->TjLow("Hello world!");

am i doing right?

from pdf-writer.

Amazing :)

from pdf-writer.

To write an non-ascii unicode, the TjHexLow seemed need some other works to handle the text encoding stuffs. If i simply convert my UTF8 strings to UTF16BE unicode string, adobe reader doesn't know the encoding. Can i use Tj to get rid of the encoding troubles?

from pdf-writer.

if you want to write non ascii unicode than you must embed a font in the regular way of using Tj with PDFUsedFont.
it will take care both of the necessary encoding and embedding (the encoding is pretty much a derivative of the embedding).

now would be a good time to ask - in what context are you planning to write? it seems to be that we are outside of the form question, right?

from pdf-writer.

Yes, i found an alternative choice other than interactive form to show my "FreeText" annotations but I need to create an appearance stream (formXObject). Without an appearance stream or a font entry in the interactive form, Adobe reader will not show my free text annotations.
Sorry to change the topics here. I can create a new issue if you prefer.

from pdf-writer.

it's ok. sound like you did just the right thing.

from pdf-writer.

A question about font:
If my Tj input texts include some CID chars, do i need to set a CID included font such that all CID chars will be rendered correctly?

from pdf-writer.

If you are using pdfused font versions then hummus will create the required cid representation. I worked quite hard on this :). You just pass utf8 encoded unicodes and make sure the font that you are using has these chars

from pdf-writer.

For example, if the text includes some Chinese chars, and i set font Helvetica (that might not have chinese glyphs) by loading the font file, Helvetica.dfont, will anything go wrong?

from pdf-writer.

Helvetica.dfont likely contains a TrueType font. FreeType can use the .dfont file directly, but we found that we had to extract the sfnt for the font we wanted from the .dfont and shove it into a standalone .ttf file. We also happen to do our own font fallback, so we look for cases where the 0 glyph is used for any character, and we ourselves look for a font that will display that character.

from pdf-writer.

Will you generate multi-textlines drawing commands based on the text input and a bounding box? or it's one textline drawing per Tj command?

from pdf-writer.

Tj (it writetext) will write a staright line. I have some measuring method somewhere so you should be able to implements wrapping yourself

בתאריך 18 באוג׳ 2016 8:10 אחה״צ,‏ magicboker [email protected] כתב:

Will you generate multi-textlines drawing commands based on the text input and a bounding box? or it's one textline drawing per Tj command?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/62#issuecomment-240790555, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAQl5-kGUajA5PaKMC8-4QpD_wtx_CKqks5qhJGtgaJpZM4JmVUq.

from pdf-writer.

Here https://github.com/galkahana/PDF-Writer/wiki/Text-support#measuring-text

from pdf-writer.

Thank you very much for the detail instructions!!

from pdf-writer.

I tested it by writing a simple chinese char, unicode = 0x5927 (大), into the appear stream (formXObject), but it ended up with 0 Tj
using SFNSDisplay-Regular.otf which includes chinese languages.

NSString *fontFilePath = [[NSBundle mainBundle] pathForResource: @"SFNSDisplay-Regular" ofType: @"off"];
PDFUsedFont *font = documentContext.GetFontForFile([fontFilePath UTF8String], 0);
PDFFormXObject *xobjectForm = documentContext.StartFormXObject(bbox, matrix);
formXObjectID = xobjectForm->GetObjectID();
XObjectContentContext *xobjectContentContext = xobjectForm->GetContentContext();
xobjectContentContext->q();
xobjectContentContext->BT();
xobjectContentContext->rg(r, g, b);
xobjectContentContext->Tf(font, fontSize);
xobjectContentContext->Td(x, y);
xobjectContentContext->Tj([contents UTF8String]);
xobjectContentContext->ET();
xobjectContentContext->Q();
documentContext.EndFormXObjectAndRelease(xobjectForm);

I traced your source codes and found It failed in PDFUsedFont.cpp
status = mFaceWrapper.GetGlyphsForUnicodeText(unicode.GetUnicodeList(),glyphs);
The unicode contained a chinese char, 0x5927 = 22823, and GetGlyphsForUnicodeText returned eFailure.

from pdf-writer.

Right. It can match the unicode value to a glyphs id. It normally works, fonts have unicode mapping that free type reads. If you can find a method to figure out the glyphs id, then hummus can accept glyphids directly with an over Liad of tj

from pdf-writer.

I tried the other font, "PingFang.ttc".
It seemed converted to a wrong hex string "<30393566> Tj".
Instead, it should show "<5927> Tj".
I traced the code and found it encoded the string with glyph index, but the hex string of Tj should be the text unicode, isn't it?

from pdf-writer.

nope. it should be the glyph index. It is the glyph index as it is in the embedded font representation.
In most cases of True Type fonts (per the algorithm i chose, and i think this is what most do) this would be pretty much the original font glyph index.

Did it come out ok?

Gal.

from pdf-writer.

It didn't show up in acrobat and other pdf readers. That's why i went to check what some pdf annotate apps generated for the single chinese char. They all show unicode encoded hex string in Tj.
Do you need me to provide the generated pdf sample?

from pdf-writer.

What we do when GetGlyphsForUnicodeText() fails is to scan through our original text and for any characters that cannot be represented by the desired font (e.g. it simply does not have any glyph to show for that Unicode character), we do our own font fallback to find an alternate font that does have a glyph for that Unicode character. For example, when we have mixed Asian text in Helvetica, we will generally find that it will fail to obtain glyphs in the Helvetica font for some Chinese characters, and so we use other facilities in the operating system [e.g. CTFontCreateForString() on Mac, IMLangFontLink class on Windows, etc.] to identify an alternate font to show those characters.

from pdf-writer.

The font, "PingFang.ttc" did have the simple chinese char and generated the hex string with Tj operator. However, it didn't show up in pdf readers.

from pdf-writer.

On the Mac, that's /System/Library/Fonts/PingFang.ttc, I guess. What is the Unicode codepoint of the character you're trying to display? I think PDFWriter delegates much of this character-glyph mapping to FreeType if it can for TrueType and OpenType fonts, and it may be that you have to go a bit further to explicitly select a charmap at the FreeType level with FT_Select_Charmap().

from pdf-writer.

I put a chinese char unicode, 0x5927 (大). It means "big" in english.

from pdf-writer.

PingFang.ttc contains something like 18 fonts. Did you pick any specific one in that file?

from pdf-writer.

No, what should i do to select a "sub-font" in the library?
I used the Tf and then Tj function calls
AbstractContentContext::Tf(PDFUsedFont* inFontReference,double inFontSize)
AbstractContentContext::Tj(const std::string& inText)

from pdf-writer.

GetFontForFile can have a 2nd parameter to select a font by its index, when using a font package. by default it picks the first one (0).

from pdf-writer.

i'm not getting success with PingFang for regular romans either (appears blank). this might mean a problem in embedding. the glyph index makes sense?

from pdf-writer.

ok. i tried some old versions of hummus. they were defo functioning better in terms of unicode work.
i'm gonna get to the bottom of this.

from pdf-writer.

@magicboker @TheGS
seems like i had a really bad bug with the creation of fonts containing unicode charachters. something that i recently introduced that ruined hex representation of chars.

in any case, i fixed the issue now.

now its seems like i can get 0x5927 to appear correctly with the windows simsun.ttc font and with mac PingFang.ttc.

i say not too bad for a day of work :). that was a ghastly one.

from pdf-writer.

Good job. What about ligatures output by TeX or TeXmacs, not being spoken
by Android PDF readers? How to make it pronounce the ligature (fi, ff)
glyph as the glyphs it stands in for would be pronounced?

On Sun, Aug 28, 2016, 15:57 gal kahana [email protected] wrote:

@magicboker https://github.com/magicboker @TheGS
https://github.com/TheGS
seems like i had a really bad bug with the creation of fonts containing
unicode charachters. something that i recently introduced that ruined hex
representation of chars.

in any case, i fixed the issue now.

now its seems like i can get 0x5927 to appear correctly with the windows
simsun.ttc font and with mac PingFang.ttc.

i say not too bad for a day of work :). that was a ghastly one.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACslilphw4gFc1rtOCK2BJ3tmlPYmAwks5qkgRDgaJpZM4JmVUq
.

from pdf-writer.

Complex text shaping (which includes the many-to-one glyph substitution to ligature glyphs) is beyond the scope of FreeType by itself.

For us, we do extremely simple glyph substitution before handing the text and glyph lists off to Hummus (this along with other geometric transformations lets us do Asian vertical text), though we haven't attempted the many-to-one substitutions required for ligatures yet.

Adopting a cross-platform text shaping library like HarfBuzz would probably solve this problem, though it might require updating the FreeType bundled with Hummus, and the last time I checked (a while ago), there was something of a circular dependency between FreeType and HarfBuzz.

from pdf-writer.

Thank you for helping us new people learn more about how it all works.

On Sun, Aug 28, 2016, 17:30 TheGS [email protected] wrote:

Complex text shaping (which includes the many-to-one glyph substitution to
ligature glyphs) is beyond the scope of FreeType by itself.

For us, we do extremely simple glyph substitution before handing the text
and glyph lists off to Hummus (this along with other geometric
transformations lets us do Asian vertical text), though we haven't
attempted the many-to-one substitutions required for ligatures yet.

Adopting a cross-platform text shaping library like HarfBuzz
https://en.wikipedia.org/wiki/HarfBuzz would probably solve this
problem, though it might require updating the FreeType bundled with Hummus,
and the last time I checked (a while ago), there was something of a
circular dependency between FreeType and HarfBuzz.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACslhMBwumhqIhPrly-SweEnawmKDchks5qkhofgaJpZM4JmVUq
.

from pdf-writer.

this looks promising:
https://github.com/tangrams/harfbuzz-icu-freetype

[icu would be nice for bidi]

from pdf-writer.

Great job!! galkahana!

from pdf-writer.