Hummus PDF

Hi!

Bit of AI related updates for the various pdf related projects:

You can now encrypt or decrypt PDFs with the help of a Claude code skill. Pick the skill up at the pdf-recrypt project page here. (Readme for instructions, or just go copy .claude/skills/pdf-recrypt).

Similarly, you can use pdf-text-extraction to extract text from PDF capabilities with Claude code skill as well. Skill is available in the project page here. (Readme for instructions or copy .claude/skills/pdf-text-extraction. Now you might ask…why do i need that Claude can get me PDF text…that’s true, but with Claude the technique is more complex (means rendering to image and then OCRing), which is not as fast, and less accurate. This is probably most meaningful when doing this en masse.

One other thing I did already a while ago is to take Claude for a ride looking for vulnerabilities in PDF Hummus library itself and fix them. Got to fix a lot of stuff, and develop some decent skills for doing this again in the future. Also a fairly neat CPP testing skill, which comes in handy in general. You get a v4.9.0 release which is safer to use.

Hi!

New release for PDFWriter, version 4.7.0 supporting PDF2.0 Encryption.

This means:

PDF2.0 files can be created and if provided when user/owner passwords are provided. The result is an AES256 encrypted file, with the required PDF declarations provided.

PDF2.0 files can be parsed, when provided with a password.

Files with PDF2.0 encryption can be modified, and the modification process will retain the encryption method.

PDF2.0 support requires a pre installation of OpenSSL library. OpenSSL is used for creation of SHA (256, 384, 512) hashes, and its strong random byte generator. There’s an opt out flag - PDFHUMMUS_NO_OPENSSL - to opt out in case this is not available in your setup. The CMAKE build file will automatically use this option of the library is not available.

Good day,

Hello 👋!

PDFWriter latest release (4.5.12) includes support for fonts that contain Emojis. Notable examples for Emoji fonts are Windows Segoe UI emoji and Google Noto font. This means that writing text that include emojis will result in lovely colorful emojis, rather than black and white representations.

Emojis are very common in our daily communication and writeups and so it makes sense that they’ll also be present in PDF files. However they do present a technical difficulty in being generally different from the rest of the text - they got color, normally even more than one, and some have fancy gradients. In a way, Emojis are less text and more like images. If you are familiar with SVG file format…then they are way more that than regular text. However, from usage point of view - they are an integral part of text input, and so they are definitely - text. For instance, copying text with emojis from one application to another, you expect the text to include the emojis and show them properly, no exception. Also - you expect to be able to type emojis, not have to upload an image every time you want to use one. So…also text.

If you try to write text with emojis and a relevant font using a previous version of hummus they will come out black and white. This is because there’s a need to include special support for colorful Emojis, which is what you get with this release. The following discusses what it means to have Emojis in fonts, what PDF can do for you in general in this area and how PDFWriter deals with this.

🥳🐒🐬👀

Fonts and Emojis

Before discussing how emojis are represented in fonts, let’s talk text in general. Emojis are part of text strings and each has a special Unicode value. For example, the smile Emoji 😊 has the value of U+263A. The vomiting emoji 🤮 has the value of U+1F92E. So they are just like regular text and this is what substantializes the ability to do things like copy and paste, save in text files and all the things you can do with text.

When it comes to representing text shape in applications and in print or PDF that is done with Fonts. A “glyph” is the name we use for the shape of a character (or a combination of characters to be exact, but the point is that it’s a single drawing). To be able to display emojis we then need to have glyphs for them.

Normally glyph is just about shape. So font formats, like true type (ttf files) or open type (otf files) contain language operations to draw things like curves and lines and take great care to do this in a compact manner that still provides enough display power to allow showing any shape an artist can draw. When used in PDF, fonts are largely embedded with some addition and conversion from their original format (depending on what types of fonts PDF supports vs. what the application that outputs to PDF supports), so the same goes in PDF. This focus on shape is what allows you to apply color to text independently, and that this text would then have the color. Italic and Bold styles of fonts are simply other fonts containing those versions of the same family of glyphs (e.g. times new roman, times new roman italic etc.).

Emojis, as opposed to regular text, don’t only have shape, they also come in specific color - most of the times more than one - and therefore there’s no way to apply color to them. They also don’t tend to come in regular, bold and italic version. A bit more rigid technically…but can express much more. interesting 🤔.

True type/Open type emoji special

To allow defining Emojis there are extensions to True type/Open type format. You can read about them in Wikipedia. I’ll summarize that there’s 3 approaches:

Allow expressing emojis as combinations of true type/open type glyphs with addition of defining colors, gradient colors and combos. In effect, attempting to implement SVG using true type for drawing the shapes. This form is defined using the true type colr table (everything in true type is tables 🤪 ).

Expressing emojis as images. This is done with either cbdt or sbix tables.

Expressing emojis as SVG graphics. This is done with svg tables.

Extra data required to draw specific glyphs as colorful emojis is found in those tables. At this point there’s no one standard format supported in all applications and by all fonts (politics 😉). Fonts are normally made with a specific method at hand with fallback on default black and white drawing using the default glyf or cff tables.

Hummus and Emoji fonts

My interest in this started with an issue on github. Got a note that Segoe UI Emoji appears black and white. well why wouldn’t it? then found out about colorful emojis in fonts, and in particular about the colr table. Segoe only uses the very simple version 0 of colr, which just defines an emoji as a list of pairs of glyphs and colors. To draw the emoji you iterate the list drawing the glyph in the particular color, one on top of the other, to get the final glyph. I implemented this part. Thanks goes to FreeType for implementing parsing of Colr table so I don’t have to, and could focus on translating this to PDF commands and structures. Thank you Free type 😃. You can see a usage example in the test file PDFWriterTesting\ColorEmojiColr.cpp. here’s how it looks like in the PDF file:

I then figured I probably want to continue this and implement Colr V1 as well, which is the complete version of colr, allowing to draw not just solid colors and layers of glyphs. Rather you can now do Gradient colors and combine glyphs in many multiple transformations. There’s special blend modes too. You can read all about it in the specs at Microsoft or Google. The google one has a good link to some sample Colrv1 fonts, including a version of Noto defining it’s emojis using Colrv1. Noto is way more interesting than Segoe containing some emojis with awesome gradients. You can see an example of using this font in PDFWriterTesting\ColorEmojiColrV1.cpp. That result in this:

I did stop here and did not continue to SVG and the image based tables. Figured that’s good enough for now.

Implementation details

Emojis are available when you draw text using a content context WriteText command. When encountering a glyph that has references in colr tables the regular drawing of text is suspended and the glyph is drawn individually using either it’s Colrv1 definition or Colrv0. This means that if the text contains only regular characters it will continue to be displayed as it is now (probably using a single PDF Tj operator).

The classes LayeredGlyphsDrawingContext and PaintedGlyphsDrawingContext implement Colrv0 and Colrv1 drawing (respectively). The Colrv1 format contains multiple operators and most of them are supported (see below for limitations).

The drawing of gradients is heavily borrowed from a similar implementation in Google Skia library. Specifically the SKGradientShader interface, PDF outputs and code of SkPDFGradientShader. It’s thanks to that that we got them, cause I’m not an expert on gradients, at all. It’s really helpful that they got this lovely fiddle that both shows what comes out and can emit PDF. truly remarkable work. No wonder it’s used everywhere haha.

I must say it’s almost a bit of a wonder how the definition of gradients in Colr resembles what’s available in Skia shaders…but then i’m guessing the connection is that both are inspired or attempting to implement SVG.

Also, as stated earlier, I used Freetype to parse the colrv1 and colrv0 table information, and they did a top notch work as well…didn’t have to parse a thing myself.

limitations and caveats

Both through some time limitations (meaning till I stated getting tired) and implementation details there’s some issues with this implementation. They mostly mean there might be some emojis that appear incorrect in relation to how you know the font should look like. here’s a list:

Implementation is done on WriteText only. Other text operators still only support regular chars and the black and white fallback for emojis (if one exists). So, for instance, Tj does not have emoji support. The reason is mostly that using Tj and other operators entails being able to rely on text state elements (like matrix set in Tm) and that drawing an emoji goes well outside of simple text drawing an uses more complex graphic elements such as cm matrixes and PDF Patterns and transparency.

I left out implementing blend modes via the Paint Composite operator for now. it’s just more work that I’ll do based on general (and mine) interest. would appreciate a sample of a glyph using something that’s not just srcOver (which i did implement).

For Sweep gradients I only did 0…360, so you can’t choose a different angle range (smaller, that is). Mostly because Skia PDF output seems to have the same limitation…and i’ll need more time to figure this out, and figured it can wait.

For Gradients (with or without alpha channels) I’m using Patterns. This is how one would draw a gradient. Nothing exceptional about that. The problem is that Patterns ignore the current matrix set by previous operators, or by elements (say if it is used in a for XObject) and deals directly with the default matrix of the page. While i could take care of providing the matrix including the WriteText position (translation) and whatever matrixes that exist within the emoji glyph drawing, any previous applications of matrix are ignored. This may result in the glyph appearing without color, if there was a shading, and you defined an external matrix. It also means forms including such a text can only be reused under the same transformation matrix. This includes Not being able to show properly when simply placed (without scaling or rotating) in another location. This is a truly annoying limitation of patterns…but that’s what it is. If you are using WriteText as is without a previous setting of matrix, it should be ok. If you did setup a matrix prior the problem can be solved by providing this Matrix to WriteText so that the pattern definition uses it in addition to its internal computation of matrix…i’m not allowing for that for now. If you are interested, let me know and i’ll find a way to pass this matrix through.

Oh and one more thing

One side effect of this is that now there’s class that can provide gradient patterns for you to use. ShadingWriter provides interface for creating radial, linear an sweep RGBA shading patterns that you can use independently of text creation. Initialize it with an ObjectsContext and a DocumentContext that you can get from PDFWriter and then it provides functions to create each gradient by being provided with parameters. Didn’t bother much with documentation (As always). If you are interested and can’t understand how to use it, let me know and i’ll provide a write up and examples.

That’s all for now.

XOXO,

Hi, Quick note about new stuff with PDFHummus C++ library.

I decided to sit down and learn some more cmake, which led to an attempt to make PDFHummus into a cmake package...which seems like it succeeded.

So, thoeretically speaking without knowing much about your current setup, there's no longer need to do some custom ExternalProject or copy the library code to your project. Rather you can either use find_package(PDFHummus) if you installed PDFHummus already or use FetchContent to grab PDFHummus from its github repo and install it in your project (as well as try to find a local copy first), and then its just a matter of target_link_libraries (<YR TARGET> PDFHummus::PDFWriter) to link your code to PDFHummus (it does headers includes too...so don't worry about that).

There's an example in my pdf text extraction project which one can learn from here (which b.t.w now supports extracting tables!!1 [well...tested a few word and google docs and it seems fine] check it out). Tested there to make sure that the new PDFHummus install method works both with local install and grabbing and building from the repo.

I'm not sure how well it serves installations with USE_BUNDLED option off though. That is those that attempt to use system libraries for PDFHummus dependencies. Might want some feedback to understand how to better support this use case.

Is all.

It's been 3 years minus 6 days since I stopped providing support for the C++ and NodeJS versions of Hummus PDF library.

Back then julianhille picked up providing support for HummusJS in his drop in replacement Muhammara. He has been providing updates since with a growing community on the projects repo. It's a simple drop in replacement for Hummus that you Can and Should use instead of HummusJS. Muhammara, for the very least, provides updates to binaries per NodeJs updates and sercurity corrections at a level which the HummusJS no longer provides, with me no longer supporting it. There's currently 18K downloads a week for HummusJS and 10K downloads for MuhammaraJS...So I hope those numbers will change in favor of MuhammaraJS with this encouragement.

As for HummusJS itself, I'm keeping it up, for those of you who still need to transit, and for my own personal projects. The API, as it did for the past 11+ years, will not break, so there's no immediate todo here for you peeps. The C++ version remains as is...as it manages to maintain itself...C++ don't do deprecations so much, and you guys been forking it to your needs so we're good there.

I'll take this chance to also recommend an accompanying library that chunyenHuang wrote a long while ago which provides simplified API to MuhammaraJS (and HummusJS prior) called Hummus Recipe. It should help you with common tasks where Hummus API might be a little more advanced.

As chances are taken i'll use the remainder of this post to review some repos on my account related to PDF that show what kinds of things you can do with Hummus Lib (or it's more up to date counterparts). Hummus is very flexible, and can provide for many different requirements around PDF files either in reading, writing or manipulating them. It's insistance on performance makes it great for server side production, or batch production of large PDFs or for quicky parsing and extracting data from PDF files (say for your AI apps).

So:

PDF Text extraction CLI(C++): parse PDF file for the text it contains, writes the collected text to stdout. A neat example of how to use the library interpreter for PDF pages, which you can use for many different things, like text extraction, images extraction and even...if you got nothing better to do with your time...rendering. It is also an example for how to include Bidi support with hummus, bidi being biderectional text. This is used to determine how to convert the logical appearance of text (being always left to right) to visual (which could be either or mixed).

Adding or Removing password CLI(C++): provide password and encrypted pdf and get a new unencrypted version...or the other way around. Uses the powerful recrypt method of the library to recreate a fresh version from an original PDF. Also good to "fix" PDF files that cannot be shown on some PDF viewers (drops old parts of the PDF no longer used etc).When a password protected accounting pdf is provided I use it to drop the password prior to storage.

Various JS examples: Repo containing implamantation examples to tasks using the JS version library:

extracting text

reading form values

filling form values

"locking form" (converting a live pdf form to a print ready read only version)

advanced import of PDF pages into target PDF file, along with the original comments

Transparent Tiff support(C++): example for importing tiff images along with their transaprency data so that the background shows properly behind them. This example can be used to learn how to import image formats that Hummus higher level api does not currently support, or create your own pixel images through data.

Hummus Report - A declerative layout engine I wrote for HummusJS to draw PDFs. It's my go to when I need to generate PDFs, with simplified text reflow support, and bidirectional text support (so...an example of how to provide right to left text to hummus).

Hummus Services - An example of how to develop a sass service over hummus. Using Hummus Reports as layout engine and ticket description, it implements a general purpose PDF generation service. hummus client is a backend client to this server, and form filling is a really old example of how to use this service as the complete backend to online form filling service, where you can overlay text and image over a PDF form and get a final PDF as a download.

Hello Hello, I used the past few weeks to renovate an old project of mine, and it's now ready for sharing.

It's a PDF creation service over the cloud. So the next time you need a site to generate PDF from scratch or overlay some content over an existing PDF (As you would when filling a form), You can have this available with some API calls to the service, instead of having to do it yourself. Server-less as the not so cool anymore, not so young anymore kids calls it. The service provides also storage for the PDFs, so you don't have to worry about that too.

And here's the deal. I'm not really gonna deploy it and make a biz out of it. At least that's not my intention now and wasn't 6 years ago when I last worked on this project. A different person might have...but I'm only here for the crafting, i'm afraid.

But that doesn't mean you can't. If you are interested here's the github link to the project. It's fully Opensource with an Apache 2 license which is very permissive: hummus services redux.

There is a live demo here - services.pdfhummus.com - but depending on how interesting or not it is to people I might take it off. It costs $$$ better spent fun and games.

And there's a really simple jQuery based web site I developed a few years back that implements form filling over this service, as an example. here's the code and this is the site - forms.pdfhummus.com. it's really old. doesn't even deal with dragging on yr touch device. Yap, you'll need a computer for this.

The service generation engine is built on top of my basic...but so far for my purposes powerful enough...layout engine called hummus-reports, which in turn is built on my hummusjs Node PDF lib, which in turn is built on my hummus C++ PDF lib. All open source, all free. Cause I can haha.

What it can do for you

PDF files are extremely common. We get them as receipts from our services providers, we use them to share contracts, we fill && sign them when we submit a request to some bank or government branch or whatnot.

Well, if you got a project that needs PDF generation there's quite a few choices, and this one here is the one that says - You don't have to have a setup for this, just send a JSON description over and you'll get back a PDF. As simple as that. As an example (on top of the form filler I discussed) I once created a site for my Sisters business that allowed her to create invoices for her customer. Login and DB was taken care of by firebase, and PDF generation by an older version of this service....so the site was just static frontend.

There's documentation of what the JSON description can contain in the live site here or if it's not available you can find the sources here. If neither is convenient, there's the documentation of the underlying engine, here.

But basically it can:

write text, including wrapping and placing inline images to flow with the text

draw images

draw shapes

append content from other PDFs

create overlay over existing PDF documents

encrypt documents with passwords

position elements dynamically based on other elements content to create tables and lists

This feature-set can be extended to support more things, based on what hummusjs can already and can be extended to do. like (again...not there...can be extended):

Fill digital forms

Parse digital forms, so you get a json of the values for a PDF

Get the text from a PDF, as a text file

Drop a password from an existing PDF (you'll have to provide the password of course..we're not doing hacking here...but you'll get back a password-less PDF) as well as Create/Change a password for an existing PDF, all based on hummus recrypt capability.

And many other tasks around PDF, built as a service rather than as a module to run on your server and take your precious application server time. And if you got multiple projects generating PDF files...well that just means you don't have to rebuild it.

A bit about arch

There's not much of arch here, but what there is i'll describe. There's a frontend here, for the jobs management and a playground for one to test their JSONs prior to using in production, and API keys management.

There's backend to support it, and also implement API keys based access. So job generation in either way works off the same server. I could, if i'd want, make the generation functionality into a micro-service I can scale on demand, but for now that's good enough.

There's also a CRON job aimed at deleting files that are marked with expiration.

All this can be deployed to a Kubernetes cluster. Got XP on this project with Minikube for and Google's cloud GKE.

The DB for the service persists data about:

jobs

files generated from jobs

users

api tokens (used also for implementing the refresh tokens. access is jwt)

some auditing for the purpose of determining the users plan usage, like recording jobs created and files downloaded.

There's some side services:

Mongo DB used for storing the DB. did make a point to never send to the client and _id to avoid exposing that. bit of a security thing (though silly if the code is opensource haha). in case y'r reading the code and not understanding what's those uids.

AWS buckets. used for storing the PDF files. To my shame I didn't write a google storage alternative even though already 6 years ago i was deploying the project on google app engine (though I don't think they had buckets then), and I am deploying the project on their GKE now.

Google Recaptcha. used to secure login and signup from brute force attacks. You can turn it off, if you don't feel like dealing with this.

Sendgrid emails. Used for sending introduction emails to users signing up and notify site admin about them. You don't have to have this and this can be turned off easily. Google used to give free credits for them 6 years ago :( .

Why did I bother with it

So if i don't mean to make a biz out of it, why bother. I have the old service code and nothing works there but why do anything about it.

Well very simple. I had the time. Just quit my job two weeks ago, and decided to take some time off. Away from people and their problems haha. I guess I could go to the beach. But I wouldn't mind some coding.

And then there's this code here of a server that's really old and I can reimplement it with more modern methods, and take this chance to close some knowledge gaps.

So, for instance, I did work with Kubernetes and had some minor exchange with ArgoCD, Kustomize and Terraform, but was always concerned about not knowing how to setup a cluster from scratch, as this was mostly at the hands of other devops. So I used this project to complete my knowledge there, and see that it's not too bad. The live service is hosted on GKE, and I created helm charts to deal with the deployments so I don't have to work hard. For local dev I used minikube to run a local cluster. Good fun. Didn't know much about minikube or helm prior...now I do and it's jolly good fun. Plus also how to create a cluster on GKE and hook it to my cloudflare setup and on to my DNS. so you can just go services.pdfhummus.com and it just bloody works (If i hadn't taken it down).

For my local setup I even went as far as setting up a cutesy EFK (Elsatic search, fluentd, kibana) just so i can easily track logs of the service. And Prometheus/Grafna...though frankly if I make this a live project I'll use datadog or something for all of this work. They do a fine job there and I don't mean to repeat it. But i reckon i'd have to pay...and this EFK setup is free for my local stuff...so good enough. Again..things i didn't know much about...now i know a little. Least enough to get good logs.

oh. The form filler sample site is sitting on bucket in aws, delivered through a cloudfront distribution (to allow https, which on a bucket only setup is not available. plus it gives cdn caps) and on to my cloudflare setup for DNS.

I also, for no good reason, never got around to writing a server in typescript, but just regular node (in the JS realm, that is). I got used to writing typescript for scripting and frontend, but never got to write a server with it. So now I did...and ok...I guess there's an example available for me now if I ever have to do it again. Bit bummed down by not being able to generate openapi from it like I could with fastapi over at python's...but it's not a deal breaker (nothing that's gonna make me use tsoa. you'll have to do better than that to get yr dynamic openapi generation from me. i'd rather build it in postman for a much smaller effort and retain my lovely middlewares style of writing and combining routes functionality thank you). Anyways, had some fun with setting this up. Wasn't working super nicely with module aliases (@lib/whatever) but now it does and now i got an example. oh - and the vscode setup to debug all his.

Over at the frontend I replaced the old Angular1 code with React, which was nice. Used a lot of sass back then, so replaced it with styled components+classnames+nesting, which provided me with the same convenient UI development method plus the occasional ability to write reusable components as styled components...when i choose to and when it's right. So a bit of getting practice for this method.

Oh..The old site used Boostrap for UI. So to make the transition easy...and allow me to copy the design, I implemented the UI with React Boostrap, and not something fancier as the kids like to today.

Conclusion

Beach time! Well, for the very least it'd be nice to not having an itch to scratch like this project around so I can really enjoy this time off.

I will probably be looking for my next workplace/project/thing in 2 months. So if you got something interesting that you think I can help you with, lemme know. For the very least i'll write down your contact details and approach when I'm done with "doing nothing". Got my github, here's my linkedin.

Hi. Got back recently to a bit of PDF hupla. It requireed me to actually interpret content stream. This being something that's probably worthwhile to others, I put the chief interpreter in a nice hopefuly convenient form - here.

The project in which this code is in, serves as an example of how and for what purpose one could use it. It is a port (and some upgrade) of an old JS project i did for extracting text with hummus. This one is now in C++ (so after four years ppl got the port they asked ;)) and i implemented on top of this interpreter.

You can use it as is, are pluck out whatever you need for your own intepretation needs.

Project is all here - https://github.com/galkahana/pdf-text-extraction.

Hi All, Thought I'd make it a little bit official. It's been quite a while that i'm not really supporting PDFWriter or HummusJS any more. Somewhere between being too busy with other projects, as well feeling kind of less interested with this project. It's been more than 8 years since I posted the first version of PDFWriter and about 6 years since HummusJS came to be, and I kind a feel it's time to let it go.

As such, I'm letting you all know that I'm officially no longer support them. I won't be taking off the github projects nor the NPM package, however I will no longer respond to questions, requests or anything that has to do with PDFWriter or Hummusjs. I'll let the community interests take over from here.

The code itself will still retain it's license (Apache 2), so you can use it as is, of course.

Thanks for everyone using those libs. I'm glad that this is useful to so many and hope that while support from me is terminated, that you'll still be able to use the code.

Hi Everyone,

A quick one from me - just published HummusJS 1.0.96.

Per Issue #364 Hummus could not be used in the context of the relatively new NodeJS Worker threads. I hope to have taken care of this issue with 1.0.96. I also cleaned up a bit of the deprecations happening with the V8 engines used by Node10 and Node11. Hope didn't create some new issues in the process, CI seems happy ;).

Hi All,

Since I posted the form filling example there have been quite a few issues submitted. I kinda hoped for an able programmer to improve the sample, fix bugs or what not, according to what issues were experianced by the community, sadly this didn't happen.

Well, not too bad. I guess I can look into the specs again and the sample files that you brought me and try to figure a solution. Now I'm not comitting on reoslving all issues, but I'll try to add a few more PDFs to those which the sample code is relevant to.

There's a couple of issues which needs attention:

The text appearance creation code is naive. It uses the embedded font and cant really figure out things like the text width and height to properly center or align the text. Also it might be that the characters are not encoded properly, or not there. Hence - the end result will not show the text, or will show it misplaced.

The form might be "XFA". This is an additional entry in the form object which needs to be updated in addition to the updates that the sample already takes care of, if that damn XFA entry is in the form. Wasn't aware of it at the time, I didn't even look at it...so i'm guessing I'll need to read about this XFA format and figure out how to update the values there.

The form might be encrypted and may used acrobat extensions and signatures and horrible things, so as to make if very difficult for a script to auto-fill the form. troubles are expected, i guess, as soon as one sees that the PDF file containing the form is encrypted. About this part im not sure I can do much, cause studying the Adobe extensions and trying to hack them is way out of scope for me.

I'm already providing a quick and dirty solution to problem #1 here - https://github.com/galkahana/HummusJSSamples/commit/5c7b531334dfb2fc59dc74cf62bb454ced204c18 You may now provide "options" object as 3rd param, and text options structure to it as "defaultTextOptions" to determine how to render the text in the form. you can be helped to figure out what to provide by either prior knowledge or by reading into the "da" string. you can see what the "da" string sais by setting "debug:true" on the same options object. then read the da...and you'll probably figure it out.

A better solution whould be to parse the DA, and only require the user to provide a mapping from PDF font name to a system font (something which is more "rendering"ish and is out of scope for hummusjs. you'll have to figure this part out yourself).

My next move would be to try and figure out if i can help with this XFA object, and then try and revisit the new code and see if i can parse the DA easily so as to grab the size, color and PDF font name from there, and then just leave the PDF font name to System font file mapping as a user requirement.

and still, if anyone want's to have a go at improving things here - be my guest. I'd much rather look into compiling PDFWriter to Javascript with emscripten, or just spend quality time staring at my wall.

Hello everyone! Had requests provide prebuilt binaries for more than the unix/mac envs that I had. Following Mr. Haidar PR for prebuilt binaries for Electron, I completed the move with Windows binaries and hopefuly we also have musl based binaries as well.

Now we have:

win, mac, unix - Node 4,5,6,7,8,9,10

electron - Electron 2.0.7 and 1.8.7 with Node 8 (Not expert on electron but it prbbly means 2.0.* and 1.8.*), on win, mac, unix

musl - Node 8,9,10 on mac, unix

Folks,

Quick release there. This one will handle errors a little better. Looking for a key that doesnt exist in a pdf dict? Would crash till this version,now returns a nice undefiend.

Reason it wasnt is just cause i got lazy to update some of my code since node 0.10, imagine that.

So, should be easier to pluck them errors now.

Xoxo,

Hello everyone!

Came back from Hunstville Alabama where I was participating in a launch of K Health App, only to find out that my precious lil hummusJS was accused (!) of harbouring a potentially harmfull dependency via an old version of node-pre-gyp. So, we now have an update. Unfortunately the new version of node-pre-gyp doesn't seem to play well with node 0.10, and while i see some action there (?) to remedy the situation it means that we're temporarily off with it. If you really must use hummus with 0.10, refer to an older version of HummusJS.

Hi All,

A fresh update to PDFWriter/HummusJS:

PDFWriter/HummusJS got a minor fix to allow it to compile with C++17 (can do this in VS2017 etc.). Got it in both codebases, though it mainly affects the C++ elements. thanks mathiasborn.

HummusJS: Got PDFRStreamForBuffer of lucianolucianoluciano into the fold, to allow you to base reading/modification off of memory buffer. A minor issue with the code causes inflation of size when was used in modification scenarios, so I fixed it and it should be fine. Thanks for that, been using it myself in a project. Thanks richard-kurtosys, the investigations he made showed the importance of this addition.

HummusJS: PPl liked using the onCatalogWrite event for adding elements to the PDF file root. And when creating new PDFs it all works very well. Problem is that in some modifications scenarios you didnt get it because the catalog is not being written. An optimization of mine manifesting in confusion. So, if you want a catalog rewrite with no questions asked, just use pdfWriter.requireCatalogUpdate() before you end the PDF, and you should be fine. Thanks marcelotavares for the addition, and chunyenHuang for his efforts in general and specifically noting to me that this would be good addition to solve many confusions.

Good Evening!

Some recent corrections and a new version triggered this small dual release.

We're looking at a new HummusJS version - 1.0.84, and a new PDFWriter version - 4.0.

The new HummusJS version adds binary support for NodeJS 9 builds (and removes all them v8 warnings that prbbly mean something to someone), and sorts out the builds for earlier version. Note that recent XCode updates started screwing with NodeJS 0.12 builds, and this is between them and them...so for the time being use some other node version, or compile on some other platform.

The new versions contain minor bug corrections, like errors with OTFs with large glyphs set (well, the max number of glyphs), errors in appending pages with inherited resouces. Also added support for InputAsciiHexDecode filters introduced by Lidia M. Also added ability to provide new forms (whether created manually or as a result of introducing images) with pre defined object IDs, so you can forward reference them where convenient. As you can see...random matters that should improve support, but nothing to go partying about ;). I admit that my main excuse is to add binary support for NodeJS 9.0, and the rest is just what got in lately but was never published.

Anyways, have a nice weekend/week. See you around.

Good Evening! PDF Encryption and Decryption got an upgrade now with added support for AES encryption/decryption. Encryption/Decryption was first introduced about a year ago, and then I had only RC4 support.

RC4 is lesser than AES in terms of quality of encryption, Plus when it came to parsing and modification it meant that some files were not allowed. So with much renewed energy I stormed this little weekend project, and punched out support.

You can read all about encryption/decryption support in the modules (C++/NodeJS) in my post from last year. Unfortunately i'm yet to write proper documentation for it, but the post is quite comprehensive in terms of the available options and reference.

In terms of versions that support this you got:

PDFWriter version is 3.9.

HummusJS version is 1.0.82.

One other thing that you should know about this new version is that there's a possibly breaking change for you. I made the default version for PDF creation be 1.4, instead of 1.3 as it was till now. This is something that I should have done in the last release when I added PNG support, to match the added transparency requirement. If you are positive that you are not using PNG support - you can go back to 1.3 by providing a version parameter when creating a new PDF file.

Now for some details about AES support.

AES When creating files

AES encryption is the preferred method of encryption for "newer" PDFs. That is, any PDF with level >= 1.6.

To match, you don't need to do nothing much in order to ask for AES encryption when you Create PDFs, just set the PDF level of the created PDF with level >= 1.6. For an example, see here for a NodeJS example, and here for a C++ example.

AES When parsing files

Hummus will automatically realize it when a file is encrypted with AES and will parse in accordance. You should just provide a password as you would have in earlier cases.

One thing of note. There are some encrypted files that don't require a password (for real). Hummus can handle those too.

AES When modifying files

When modifying files, the original encryption is used when writing new content. So if the original was encrypted with RC4, new content will be encrypted with matching RC4 encryption. Same goes for AES. nothing for you to handle in a special way. Lib will take care of this.

Recrypting

Back when I wrote the encryption/decryption algorithm last year, I introduced the recrypt method for the two modules. You can read about it here.

The original purpose was to allow stripping a PDF from its password, or adding a password to an existing PDF, or change the password or whatnot. Internally it was simply creating a new PDF with whatever options you wanted, in terms of encryption.

Turns out that it can DEFO be used also for cases that are not about passwords at all, such as in the case of creating a version of a PDF file that does not include its incremental updates - but rather only the current up to date content. Very good to recreate a file for those readers out there that can't handle modified files.

Thing is that the level of PDF for the new PDF was taken from the original PDF. Now that we have this new option to get a better encryption, I figured that it'd be useful to add an option to recrypt for setting the level of the new PDF. So if you want AES, for instance, and the original was a 1.4 PDF (allowing support for RC4 only), you can provide 1.6 as a level, and get a better encryption. This goes the other way around too (this would be useful if your expected target reader cant handle PDF of levels > 1.6).

C++ version of recrypt is therefore updated to:

static PDFHummus::EStatusCode RecryptPDF( const std::string& inOriginalPDFPath, const std::string& inOriginalPDFPassword, const std::string& inNewPDFPath, const LogConfiguration& inLogConfiguration, const PDFCreationSettings& inPDFCreationSettings, EPDFVersion inOveridePDFVersion = ePDFVersionUndefined); static PDFHummus::EStatusCode RecryptPDF( IByteReaderWithPosition* inOriginalPDFStream, const std::string& inOriginalPDFPassword, IByteWriterWithPosition* inNewPDFStream, const LogConfiguration& inLogConfiguration, const PDFCreationSettings& inPDFCreationSettings, EPDFVersion inOveridePDFVersion = ePDFVersionUndefined);

Note the last parameter - inOveridePDFVersion - you can provide a PDF Version Enum for the new level. Leaving as is will retain the original PDF level, and is the backward compatible version.

The NodeJS version already had a version parameter available, but it wasn't doing anything. So from now on - it will. Provide the new version through it, like this:

var pdfWriter = hummus.createWriter( __dirname + '/output/PDFWithPassword.pdf', { userPassword: 'user', ownerPassword: 'owner', userProtectionFlag: 4, version: hummus.ePDFVersion16 });

Next

Well, that's all for today. This should clear out some parsing failures that you folks had.

Seems like what would be best to invest in next is not so much as dev, but rather do some work on documentation. Hummus is very rich in terms of what it can do, and it's easy to get lost, or not find what hints there are to do stuff. So I'll look into that.

Good Evening! PNG images support is now available with new released of PDFWriter (which is for quite some years also a reader and modifier) and HummusJS. Both Opaque and Transparent images are supported, rgb, grayscale, interlaced or not.

PDFWriter version is 3.8. HummusJS version is 1.0.81 (will there ever be a 2?!).

The support of transparency for PNG is unique within the context of images support, and allows for overlaying images in more sophisticated manner than was available so far. A common example is the wish to use a signature image on top of existing pages as part of a form filling implementation - so far one would get the image background hiding whatever is behind. Now with PNG, one can use a transparent images and avoid this effect. (will be very useful for this on-line form filling page).

Showing PNG images in both library versions is available through the local high level DrawImage variant. In addition both libraries provide a Form creation methods supporting both file input and custom stream input.

Documentation:

PDFWriter (C++) :

DrawImage

CreateFormXObjectFromPNGXXXX

HummusJS (NodeJS) :

drawImage

CreateFormXobjectFromPNG

Examples:

C++ : PNGImageTest.cpp

NodeJs : BasicPNGImagesTest.js