The render method should work with any writable IO object. This is good for performance as it allows writing to any stream. The method currently works with most streams, but not STDOUT (a very common choice). It's not possible to use STDOUT because the code attempts to invoke size on the IO object.

.../lib/pdf/core/document_state.rb:69:in `block in render_body':
    undefined method `size' for #<IO:<STDOUT>> (NoMethodError)

We've worked around this problem (in Asciidoctor PDF) by wrapping STDOUT in an object that tracks the length written and responds to the size method. However, it would be reasonable for pdf-core to keep track of the length it has written internally and avoid the call altogether.

The test case should check whether STDOUT can be successfully passed to the render method.

Perhaps this needs to happen in ruby-pdf, but I couldn't find that on github, so filing here:

It would be nice if PDF::Core::PageGeometry could have a 'STATEMENT' size added for 5.5x8.5-inch paper, i.e. 396.0x612.0 pts.

This is one of several possible names (Memo, Statement, Mini, Invoice, Stationary, Half Letter) for this size, as documented on wikipedia. I'd be fine with most of these names, though I'd advise against using Stationary, and I specifically chose Statement based on a web search for 5.5x8.5" size names, which lists 'Statement' for this size, and lists 'Stationary' as 8x10" instead.

There may be room for other sizes to be added, as well, based on other sizes in the table on that page (or the above definition of 'Stationary').

This is a low-urgency request; I know I can work around it by just specifying an array of point sizes. I just thought it would be a useful addition, so filing an issue to track or reject the idea. (I'd submit a PR, but it seems like the file may be generated, and I don't currently have the energy to track down figuring that out.)

Thanks for considering!

This object still has quasi-circular dependencies on Prawn, and its tests live in Prawn rather than here.

I'm the debian maintainer for asciidoctor-pdf. When creating PDF files that completely fill the last page, that application calls object_id_for_page so that it can delete an extra page it creates after the end of the output:

  def object_id_for_page(page)
    page -= 1 if page.positive?
    flat_page_ids = get_page_objects(pages).flatten
    flat_page_ids[page]
  end

There's no definition of get_page_objects in this class though, and I don't see where it could inherit one from? I put together a fake version of this function which seems to at least get past the crash, but I'm reasonably sure it isn't correct:

  def get_page_objects(pages)
    pages.data
  end

I'm afraid I'm really unfamiliar with Ruby at this level, so this may not be a bug in pdf-core, but rather something missing from asciidoctor-pdf.

Here's what the "Developing With PDF" book from O'Reilly has to say on this topic:

While the term "real" is used in PDF to represent the object type, the actual implementation of a given viewer might use double, float, or even fixed point numbers. Since the implementations may differ, the number of decimal places of precision may also differ. It is therefore recommended for reliability and also for file size considerations to not write more than four decimal places

I looked this up in the PDF standard and it too said that it's common for "real" numbers to be implemented as fixed point values. In Appendix C, 5 decimal places is recommended as a maximum.

I think we will go with 4 to be a bit more conservative, but if that causes any problems we can try bumping it up to 5. But it's clear that beyond that we can expect trouble... even the standard tells us that.

With commit db1c871, template support has been dropped. It's still accessible from prawn and just started to cause errors in my app, after upgrading to 1.0.0:

NoMethodError: undefined method load_file' for #PDF::Core::ObjectStore:0x007f81f3dc4340`

Is there any alternative solution available or any chance of reverting the above mentioned commit?

Hello,

I can see that version 0.8.1 was released, but I cannot see the source code on GitHub. This would be very helpful, because I'm working a bug in pdf-core.

Thanks!

Hey Guys,

I'm very happy to use prawn 👍

One small thing I got today is that my generated pdf has some validation issues:

1.4.1 : Trailer Syntax error, The trailer dictionary doesn't contain ID
3.1.1 : Invalid Font definition, Some required fields are missing from the Font dictionary.
3.1.2 : Invalid Font definition, FontDescriptor is null or is a AFM Descriptor
7.1 : Error on MetaData, Missing Metadata Key in catalog

So I use latest version of prawn:

gem 'rails', '4.1.8'
gem 'prawn', git: "[email protected]:prawnpdf/prawn.git"
gem 'pdf_validator'

In rails console:

# I'm generating PDF file:
Prawn::Document.generate("metadata.pdf",
  :info => {
    :Title        => "My title",
    :Author       => "John Doe",
    :Subject      => "My Subject",
    :Keywords     => "test metadata ruby pdf dry",
    :Creator      => "ACME Soft App",
    :Producer     => "Prawn",
    :CreationDate => Time.now
  }) do

  text "This is a test of setting metadata properties via the info option."
  text "While the keys are arbitrary, the above example sets common attributes."
end

# Then try to validate generated file with "pdf_validator" gem (https://github.com/bitzesty/pdf_validator):
> path_to_pdf = "#{Rails.root}/metadata.pdf"
> res = PdfValidator.validate(path_to_pdf)
> res[:errors].map { |e| puts e }
1.4.1 : Trailer Syntax error, The trailer dictionary doesn't contain ID
3.1.1 : Invalid Font definition, Some required fields are missing from the Font dictionary.
3.1.2 : Invalid Font definition, FontDescriptor is null or is a AFM Descriptor
7.1 : Error on MetaData, Missing Metadata Key in catalog

Then I also uploaded generated "metadata.pdf" file to http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx
and got some issues in results:

Validating file "innovation_award_Dec_18_2014(1).pdf" for conformance level pdfa-1a
The file trailer dictionary must have an id key.
The key Metadata is required but missing.
The key MarkInfo is required but missing.
A device-specific color space (DeviceGray) without an appropriate output intent is used.
A device-specific color space (DeviceRGB) without an appropriate output intent is used.
The key F is required but missing. (2)
The value of the key SMask is an image but must be None. (2)
The value of the key CA is 0 but must be 1.0. (2)
The value of the key ca is 0 but must be 1.0. (2)
The font Helvetica-Bold must be embedded.
The font Helvetica-Oblique must be embedded.
The font Helvetica must be embedded.
The document does not conform to the requested standard.
The document contains device-specific color spaces.
The document contains fonts without embedded font programs or encoding information (CMAPs).
The document contains transparency.
The document contains hidden, invisible, non-viewable or non-printable annotations.
The document's meta data is either missing or inconsistent or corrupt.
The document doesn't provide appropriate logical structure information.
Done.

Maybe someone is experienced with same issue and know how to fix it.

Thanks for any help 🍻

pdf-core-0.6.1/lib/pdf/core/stream.rb:21:in `<<'

Backtrace:

shared/bundle/ruby/2.3.0/gems/pdf-core-0.6.1/lib/pdf/core/stream.rb:21:in `<<'
  /home/deploy/figs/shared/bundle/ruby/2.3.0/gems/pdf-core-0.6.1/lib/pdf/core/reference.rb:36:in `<<'
shared/bundle/ruby/2.3.0/gems/prawn-2.1.0/lib/prawn/images/png.rb:169:in `build_pdf_object'
shared/bundle/ruby/2.3.0/gems/prawn-2.1.0/lib/prawn/images.rb:93:in `build_image_object'
shared/bundle/ruby/2.3.0/gems/prawn-2.1.0/lib/prawn/images.rb:66:in `image'

I am using Prawn and they switched to the new version of PDF-Core. But since the update I'm getting the following warnings on my production environment.

vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: already initialized constant PDF::Core::Text::VALID_OPTIONS
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: previous definition of VALID_OPTIONS was here
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: already initialized constant PDF::Core::Text::MODES
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: previous definition of MODES was here

Do you guys have an idea what might be causing this?
I don't get the warnings on my development environment.

All calculations in PDF::Core should be absolute, so we should move this logic up into Prawn to eliminate the dependency and clarify the API expectations. This probably means looking for similar problems elsewhere throughout PDF::Core.

Hi! I came source diving to investigate the performance of the real(number) method, but I found it was already greatly improved in 236fbf6. For now, I've forked the repo and I'm bundling from github, but how about releasing a new version with those improvements? Thanks 🙇 !

For example, something like pdf.add_instruction(:m, [200, 300]).

Readme says: "Refernce materials"
Change to: "Reference materials"

Hi,

rpmlint complains about incorrect-fsf-address[1] for GPLv2 file. GPLv2 should contain always the latest revision of the license without any modifications.

[1] http://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address