sandal / prawn
- Source
- Commits
- Network (96)
- Issues (14)
- Downloads (21)
- Wiki (7)
- Graphs
-
Branch:
master
-
Fonts are messed up when embeding image
9 comments Created about 20 hours ago by swistakThis is probably a side effect, but when I try to embed image next to text fonts get screwed up, kghost view refuses to display page at all, acrobat 8 displays it but displays unaliased fonts.
here's the code:
font FONT font_size 10 image_path = File.join(RAILS_ROOT, 'public', Spree::Config[:logo]) start_at = options.start_at.blank? ? ' - ' : options.start_at.strftime('%d-%m-%Y') end_at = options.end_at.blank? ? ' - ' : options.end_at.strftime('%d-%m-%Y') If i uncomment bellow lines everything displays nice pdf.image image_path, :at => [0, pdf.bounds.absolute_top()-10], :height => 50 pdf.bounding_box([200, pdf.bounds.absolute_top()-10], :width => 300) do pdf.text "<i>#{options.report_title}</i>", :align => :right pdf.text "%15s: %s" % [t(:start_at), start_at], :align => :right pdf.text "%15s: %s" % [t(:end_at), end_at], :align => :right pdf.move_down(5) end pdf.move_down(5) pdf.pad(10){ hr }Comments
-
Using :align option with absolute-positioned text
3 comments Created 22 days ago by lailsonbmCurrently, it is not possible to combine the
:alignoption with absolute-positioned text (i.e. when using:atoption). The text starts at the:atpoint, making it always left-aligned. It would be very useful if this point could be used as reference for centered or right aligns as well. So, when:align == :center, the text would be positioned just in middle of:at's x; when:align == :right, the text would be positioned before:at's x; and when:align == :left, the text would be positioned after:at's x, as it currently does. In fact, it seems very simple to implement this usingwidth_ofmethod.Comments
This has come up several times before on the mailing list. We don't want to support this feature as it confuses what it means to absolutely position text.
I imagined it was asking before, since it is a really basic thing. I still think it is very useful thing and many other libraries have it, as SVG and canvas, for instance.
-
website should be updated to point to new bug tracker
0 comments Created 29 days ago by sandalComments
-
would be useful for go_to_page() and other things. Returns the current page number
Comments
-
On Acrobat Reader 9.2 on Gentoo linux, the following code illustrates an issue with the color refactoring commit at:
http://github.com/sandal/prawn/commit/28393eb96734ebd017a6fc7b9c794c57a66c3f1e
What I'm seeing is that it displays the stroked rectangle correctly on the first page, but all subsequent pages are left blank. I am reverting for now. If we can fix this, feel free to pull the change back in.
Comments
-
Prawn supports jpg and png images to get embbeded on pdf it would be nice if it supports gif images too.
Comments
GIF is an old format. I'm not aware of any benefits compared to PNG other than browser support, which isn't an issue with Prawn.
The one argument for it I can think of is when you want to use the same images for web and PDF and you have cross-browser issues with PNG.
I don't see that adding this would be a big gain, and I'm guessing the core developers will not spend time on it, but may accept a patch.
Agreed, with the added concern about GIF having some legal issues surrounding it that I'm not well versed in. Closing, but will consider a patch if it comes up.
The patents are supposedly expired everywhere since 1 October 2006, so I don't think there are legal issues any longer, at least.
-
0 comments Created about 1 month ago by sandal1.0xtext_box should support font options (size, style, etc)requestxComments
-
Perhaps this is a prawn/format issue, and if so I apologize for posting this in the wrong place. In 0.5.x, you could put HTML line breaks (
) inside a cell and have the table render correctly. Since 0.6, it now occasionally adds a page break instead (and then, not always).For example:
Prawn::Document.generate('test1.pdf') do table [['A', 'B<br/>C'], ['D', 'E<br/>F']] endThe result is a 3-page pdf that looks very bad.
Comments
prawn-format has not ever been offically approved for use with tables. If you use them both together, you run the risk of things acting very strange. There are ways to get them behave, but they're hacks, really. We will update the documentation in Prawn 0.7 to make this clearer.
This issue is about the interaction of prawn-layout and prawn-format, and definitely isn't anything to do with prawn-core, though. In the future, file bugs about prawn-format there.
-
From 126f494 Mon Sep 17 00:00:00 2001 From: JeanLuc HAVY Date: Sun, 15 Nov 2009 01:45:18 +0100 Subject: [PATCH] Fixed links creation in annotations.rb In method annotations.rb:annotate a reference identifier was used instead of the actual reference. The links in generated pdf weren't working. Results in pdf were for example : /Annots [7] instead of : /Annots [7 0 R] --- lib/prawn/document/annotations.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/prawn/document/annotations.rb b/lib/prawn/document/annotations.rb index 61df1ab..e3925f9 100644 --- a/lib/prawn/document/annotations.rb +++ b/lib/prawn/document/annotations.rb @@ -23,7 +23,7 @@ module Prawn def annotate(options) current_page.data[:Annots] ||= [] options = sanitize_annotation_hash(options) - current_page.data[:Annots] << ref(options) + current_page.data[:Annots] << ref!(options) return options end -- 1.6.5.2
Jean-Luc
Comments
Oh, great catch. I thought that perhaps something with annotations was messed up, but had assumed it was an issue on my machine.
I will apply this, but if you can get it on a fork within the next day or so, that'd be great. Note that this is our official patch policy, so that while we will often be willing to manually apply bug fix patches for obvious reasons, things move faster and are less likely to be deferred / rejected if you send them to us in the preferred format.
I've got a fork at http://github.com/jlh/prawn where I've pushed the fix.
-
2 comments Created about 1 month ago by jlhPrawn-0.6.2 : extensions aren't inheriteddefectxHi,
I just upgrade from 0.5.1 to 0.6.2 and discover that my code break
with 0.6.2.
I narrow the problem down to the new 'extensions' class instance
variable (or whatever it is called in ruby terminology).
The following code works with 0.5.1 and doesn't with 0.6.2 :require 'prawn' require 'prawn/format' class TestPdf < Prawn::Document end t1 = Prawn::Document.new puts Prawn::Document.extensions.inspect puts t1.tags.inspect t2 = TestPdf.new puts TestPdf.extensions.inspect puts t2.tags.inspect
And here is the problem, 'extensions' is empty for the TestPdf class
as it isn't inherited.So if I want to subclass a Prawn::Document class, I have to add
TestPdf.extensions << Prawn::Format.So the question is : Is this the desired behavior ??
If not, maybe 'extensions' could be a class variable (@@ extensions)
which should solve this issue.Jean-Luc
Comments
This is a confirmed defect. We will fix it with an inherited hook, so as to only share extensions downstream.
-
4 comments Created about 1 month ago by atoticdocument.transaction dies with "no marshal_dump is defined for class Proc"defectxI am trying to use transactions. I am creating a complex document (ballot), and I die when trying to start a transaction every time. Here is a 10 liner reproducible case:
require 'rubygems' require 'prawn' pdf = Prawn::Document.new(:skip_page_creation => true) pdf.start_new_page pdf.font_families.update({ "Helvetica" => { :normal => "/Library/Fonts/Arial Unicode.ttf", :bold => "/Library/Fonts/Arial Bold.ttf" }} ) pdf.font("Helvetica", :size => 13) pdf.text "How are you" pdf.transaction do pdf.text "Nice, thank you" end puts pdf.renderThe code dies HERE:
prawn-core-0.6.1/lib/prawn/document/snapshot.rbdef take_snapshot {:page_content => Marshal.load(Marshal.dump(page_content)), :current_page => Marshal.load(Marshal.dump(current_page)), <<< HERE The problem is that current_page # {:Font=> {"F1.0"=> #:CourierNewPSMT, :Type=>:Font}, @gen=0, @identifier=7, @on_encode= #, @stream=nil>,You can see that font reference has on_encode object of type Proc, which cannot be marshaled.
http://corelib.rubyonrails.org/classes/Marshal.htmlFor now, my workaround will be to not declare custom fonts.
Comments
Apologies for crappy formatting, did not know about the markup.
Oh, yeah, this is probably something we can fix. We'll look into it soon.
I have confirmed that this issue exists and reduced the example down a bit farther. Transaction will just 'not work' with TTF fonts, which is a pretty severe issue. I'll get in touch with Brad and see if there is any easy way around this. As soon as we have time to hunt down the issue and fix it, this certainly would merit a maintenance release and is probably a 0.7 blocker as well. We don't want to shortchange our friends who need m17n.
bradediger
Fri Nov 13 16:21:29 -0800 2009
| link
Remove Prawn::Reference on_encode block argument, in favor of a new, more flexible callback system. Closed by 36ef89c.
Added a callback system Prawn::Document::Internals#before_render(&block),
which accepts a Proc to be run after all objects are finalized, but before
anything is rendered to the output stream. This removes the need for the
on_encode Proc argument to Prawn::Reference, so that argument has been
removed.Since we are no longer storing Procs in references, this closes issue 56.
Added a spec to verify. -
Stamped content not visible when it is close to top and right boundary
1 comment Created about 1 month ago by BluejadeThe origin of BBox is at the lower-left corner of the page. Therefore, it must be as wide and as tall as the page, not the bounds (which already account for margin), or else we get cut off at the right and top.
Fix available through http://github.com/Bluejade/prawn
-Daniel
Comments
bradediger
Wed Nov 11 15:41:13 -0800 2009
| link
Merged, thanks.
-
1 comment Created about 1 month ago by bradedigerReopened pages have wrong length in their content streamsdefectxThe general/page_numbering example shows this problem. When pages 1 and 2 are reopened, their content stream dictionary writes the wrong length (94 for page 1; should be around 170). The length does not match the actual length of the stream.
Preview on OS X reads until endstream without regard for the length; Adobe Reader 9.2 on Windows stops reading the stream at the dictionary-specified length.
Comments
bradediger
Wed Nov 11 13:33:10 -0800 2009
| link
Defer finalizing the page_content refs until the document is rendered. Closed by 1012352.
This is essential for documents that reopen pages in order to:
- Set the correct stream length in the stream dictionary - Make it possible to re-open streams that will be compressed - Not draw the header and footer multiple times if the same page is finalized more than once.The document compression specs were also broadened so as not to assume
the page_content stream will be compressed immediately after leaving a
page. -
Font doesn't work with stamps when document created with :skip_page_creation => true
1 comment Created about 1 month ago by BluejadeLine 33 of Font.rb included direct references to @current_page, instead of current_page. I've added spec coverage and the fix and pushed them to http://github.com/Bluejade/prawn/tree/
-Daniel
Comments
bradediger
Wed Nov 11 15:41:07 -0800 2009
| link
Merged, thanks.
-
Feature ticket Re: Impending Feature Freeze for 0.6 Release
0 comments Created 2 months ago by BluejadeHere is a list of features I've submitted to be considered for the 0.6 release, all available through the master branch at http://github.com/Bluejade/prawn:
>stroke dash
stroke cap style (a late addition)
stroke join style (another late addition)
transparency
stampsComments
-
Add :ignore_text_flow option for image placement
1 comment Created 2 months ago by shammond42Add option to position an image on the page, but not move the text cursor afterwards. See shammond42/prawn (http://github.com/shammond42/prawn/tree/) for implementation, documentation and examples.
Comments
I see where you're going with this, but I think it's fighting a symptom rather than the disease. We need to find a unified API for keeping the y cursor from moving. Expect to see something for that in a future release.
There is also the semi-private mask(:y) { ... } if you need something immediately and are using the standard Prawn builds.
-
Greg, Brad, I've incorporated the changes you recommended and made a few other improvements (such as a couple new specs). Please note that everything for both transparency and stamp is now on the master of my Prawn fork: http://github.com/bluejade/prawn. I hope that works okay for you.
Please let me know if anything else should be done on these.
Best,
Daniel
Comments
That works fine. I'll try to merge this soon so you don't need to worry about complications with your master branch diverging.
-
I just found what i think is a bug in the nametree << method :
That code taken from name_tree_spec.rb works ok:it "should keep tree balanced when subtree split cascades to root" do node = Prawn::NameTree::Node.new(@pdf, 3) tree_add(node, ["one", 1], ["two", 2], ["three", 3], ["four", 4]) tree_add(node, ["five", 5], ["six", 6], ["seven", 7], ["eight", 8]) tree_dump(node).should == "[[[eight=8,five=5],[four=4,one=1]],[[seven=7,six=6],[three=3,two=2]]]" endbut the same code with the values pre-ordered doesn't :
it "should keep tree balanced when subtree split cascades to root" do node = Prawn::NameTree::Node.new(@pdf, 3) tree_add(node, ["eight", 8], ["five", 5], ["four", 4,], ["one",1] tree_add(node, ['seven', 7], ['six', 6], ['three', 3], ['two', 2]) tree_dump(node).should == "[[[eight=8,five=5],[four=4,one=1]],[[seven=7,six=6],[three=3,two=2]]]" endHere is the output :
/usr/lib/ruby/gems/1.9.1/gems/prawn-core-0.5.1/lib/prawn/name_tree.rb:83:in `<<': undefined method `<<' for nil:NilClass (NoMethodError) from /usr/lib/ruby/gems/1.9.1/gems/prawn-core-0.5.1/lib/prawn/ name_tree.rb:42:in `add' from name_tree_spec.rb:13:in `block in tree_add' from name_tree_spec.rb:12:in `each' from name_tree_spec.rb:12:in `tree_add'nametree.rb:83 is "fit << value"
but fit is nil because in the previous line : fit = children.detect { |
child| child >= value }
"child >= value" is always false if the values inserted are already ordered.This patch fixes it for me :
diff --git a/lib/prawn/name_tree.rb b/lib/prawn/name_tree.rb index 267a6e9..c7d20c8 100644 --- a/lib/prawn/name_tree.rb +++ b/lib/prawn/name_tree.rb @@ -79,6 +79,7 @@ module Prawn split! if children.length > limit else fit = children.detect { |child| child >= value } + fit = children.last unless fit fit << value end-- jlh
Comments
can we get this in git format-patch format so we can preserve your authorship information?
(or on a fork)Yes, you can.
I've now created a fork at http://github.com/jlh/prawn and pushed what i hope is a real fix for a real bug.
bradediger
Sat Oct 24 13:06:48 -0700 2009
| link
Fixed in 23cafc4. Thanks!
-
Comments
-
Comments
-
2 comments Created 2 months ago by reidabdefectxREADME refers to :size and :page_orientation options, instead of :page_size and :page_layoutdocumentationxSee title :)
Comments
bradediger
Sat Oct 24 13:16:31 -0700 2009
| link
Fix references to :page_size and :page_layout in README. Closed by e36a8ed.
-
compute_width_of() seems to consider unicode as single byte character-set
3 comments Created 2 months ago by tntHello
For example for german umlauts compute_width_of() reports up to the double width of the same character without diaeresis (e.g. Ü has twice the width of U).
Here some sample code:
#!/usr/local/bin/ruby require 'rubygems' require 'prawn' pdf = Prawn::Document.new %w(wertbestätigung wertbestatigung Ä A Ü U Ö O Â A).each do |heading| str_width = pdf.font.compute_width_of(heading) pdf.text "#{heading} width: '#{str_width}' " end def print_stretched pdf, string, gap, position_y char_h = {} string_width = 0.0 offset = 0 char_a = string.split('') char_a.each { |c| string_width += char_h[c] = pdf.font.compute_width_of(c).to_f } string_width += ( char_a.length - 1 ) * gap position_x = pdf.bounds.width / 2 - string_width / 2 char_a.each do |c| pdf.text c, :at => [position_x+offset, position_y] offset += char_h[c] + gap end end pos = 400 %w(rechnung kostenvoranschlag wertbestätigung angebot).each do |heading| print_stretched pdf, heading, 2.0, pos pos+= 30 end pdf.render_file('stretched.pdf')Comments
You're using an AFM font, so your text needs to be transcoded to WinAnsi (as the documentation for Font::AFM#compute_width_of indicates)
normalize_encoding() will do this for you.
Also, you should use Document#width_of() rather than Font#compute_width_of() as the former is the officially supported API for end users. In either case, transcoding will be necessary here.
Also, if you need full UTF-8 support, consider using any TTF font that is Unicode aware and things should 'just work' so long as the text you pass into Prawn is encoded in UTF-8.
-
2 comments Created 2 months ago by jonteboldefectxDocumentation miss regarding Font#normalize_encodingdocumentationxFont#normalize_encoding is described in the docs as modifiying the argument, which it does not anymore. Font#normalize_encoding! is the destructive version of the method.
Comments
bradediger
Sat Oct 24 13:21:47 -0700 2009
| link
Update RDoc on Font#normalize_encoding to reflect that it is nondestructive. Closed by d013aaa.
-
Could width_of do an automatic normalize_encoding?
1 comment Created 2 months ago by jontebolWould it be possible (or even a good idea) to change document.width_of so that it always does a normalize_encoding automagically?
Comments
-
2 comments Created 2 months ago by jonteboltext method :at and :align optionsdocumentationxHaving both :at and :align options on the text method, makes you think they would work together, which they don't. This should be fixed, or reflected in the documentation.
Comments
-
Hi,
I got an error /usr/lib64/ruby/gems/1.8/gems/prawn-format-0.2.0.1/lib/prawn/format/parser.rb:120:in `start_parse': closing b, but no tags are open
(Prawn::Format::Parser::TagError)when displaying text like that
pdf.text "<b>this is simple plain text where plain = true</b>", :plain => true
This is working fine in earlier version.
Comments
I believe this is caused by not passing all the options through to width_of in Prawn:Document::Text#wrapped_text so prawn-format doesnt get the :plain option and tries to parse it for tags
@twalpole: that's not what it is, since Prawn::Format does some heavy extensions to Prawn and doesn't use any of the original functions. (Unless I missed something)
This is the wrong tracker, since it's a prawn-format issue.
I've recreated the ticket here:
http://github.com/sandal/prawn-format/issues/#issue/7Actually -- I believe when the :plain option is detected prawn-formats text_with_formatting calls back to the original prawn-core which it has aliased as text_without_formatting. The original prawn-core text then calls the original wrapped_text which calls "width_of(e, :kerning => options[:kerning])". This has been aliased from prawn-layouts width_of_with_formatting BUT since the prawn-core call to width_of has stripped out the :plain option (because it only passes the :kerning option for some reason) - then width_of_with_formatting no longer knows that the :plain option was used and attempts to process the text as if it contains formatting. Passing all options through to width_of should fix this issue - unless there is a specific reason only :kerning is passed
-
If a table cell is wide, the next table header wraps, or all subsequent table headers overlap into the final. This can occur in the middle of the table.
Comments
This is the wrong tracker, please create a new ticket, with a reduced example that reproduces the problem, over in prawn-layout:
-
you wrote that i should create an issue to remind you. so please apply my fixes:
http://github.com/corny/prawn-layout/commit/7524535bd421e36594ae1b64c8160fca0cb4fb36
http://github.com/corny/prawn-layout/commit/3883f8b9c6ac3b0dff017c28b3e01b8715b31d7f
http://github.com/corny/prawn-layout/commit/8738c3d51cacbf57b2452e47323a5a9d27721270Comments
This is the wrong tracker. Your changes are to prawn-layout, so this should have been in: http://github.com/sandal/prawn-layout/issues
I will look at your fixes now though, so no need to re-file.
-
require "enumerator" in graphics.rb should be removed
2 comments Created 4 months ago by bsdmadIn ruby 1.8.7, enumerator.rb doesn't exist. It's not a problem if a script using prawn is executed by ruby interpreter, however, a Windows binary generated by exerb from the script cannot execute correctly because the binary tries to load enumerator.so but cannot load it.
Please fix this issue. Thanks!
Comments
Ruby 1.8.7 is not supported at all for Prawn. Officially supported Ruby versions are 1.8.6 and 1.9.1
Since require "enumerator" is necessary for backwards compatibility with 1.8.6 and works in a normal environment, you should report this issue to exerb.
-
1 comment Created 4 months ago by bradedigerBinary sentinel in header needs to be in PDF commentdefectxThe four binary characters recommended by the spec (as a sentinel for file-transfer programs) should be in a PDF comment: "it is recommended that the header line be immediately followed by a
comment line containing at least four binary characters". Confirmed that at least Apple's PDF framework does this correctly.Fixed in bradediger/prawn@a14f21e4. Sending pull request.
Comments
-
using center layout in prawn is not correct as the length of lines is not correctly determined (incloding '\n' character)
This was published and discussed on in google group:
http://groups.google.com/group/prawn-ruby/browse_thread/thread/6754ada443dd22cd
workaround is to overwrite width_of method by manually removing tailing '\n' characters. (sorry the layout is broken as githup is always reformating this as coding)module Prawn
class Documentalias_method :orig_width_of, :width_of def width_of(string, options={}) orig_width_of(string.gsub(/\n\z/,""),options) endend end
Comments
I don't think we can make an assumption about newlines.
The documentation in Prawn already states:
"Text wrap in Prawn does not re-flow linebreaks, so if you want fully automated text wrapping, be sure to remove newlines before attempting to draw your string. "
I could clarify that a little more, but this basically means it's up to you to remove your newlines. If font designers include a width for \n, it's best for us to respect those intentions even if they don't make much sense.
fastpencil
Wed Sep 30 16:33:31 -0700 2009
| link
This particular issue is driving me crazy when using the Arial TTF font, which apparently has a width defined for the newline character, although I'm hard-pressed to figure out why anyone would want a newline to have width.
-
Including a PNG with RGB+alpha (color type 6) in a PDF is not feasible because the method "unfilter_image_data" is incredibly slow. A quick benchmark of spec/png_spec.rb with and without the tests that hit this method:
(2.4GHz Intel Core 2 Duo) with: "Finished in 13.779863 seconds."
w/out: "Finished in 0.391898 seconds."That's on a 320x240 pixel PNG. It gets a lot worse the bigger they get. I have a use case where a 474x719 PNG is included in a PDF and it takes 24 seconds to create.
The bummer here is that many graphical apps (Pixelmator, Illustrator, etc) always flip the alpha transparency bit so this affects many images.
Comments
Closing, because it's not really possible (AFAIK) to make this faster in pure Ruby. Feel free to re-open w. a patch. Or use prawn-fast-png if you can stomach the RMagick dependency.
-
1 comment Created 4 months ago by ericluowrap chinese text failed when render tag document by require 'prawn/format'reviewxI had used prawn to generate some chinese pdf documents successfully
when set the :wrap option to :character, but the wrap function failed for document which include tags
after I required 'prawn/format'.Comments
-
Allow printer's marks (bleed, crop, etc) to be drawn on the pages through use of something like :prepress => [bleed, crop] in Document.generate.
Examples:
http://www.jukeboxprint.com/images/crop_marks.gif
http://www.ewbi.com/ewbi.develop/graphics/word.crop.marks.jpgComments
It seems like there's a lot of variation in style but here's an example of Prawn doing this:
-
A bit pie in the sky at the moment, but....
grouped do # ... endWould attempt to keep contents on the same page
Comments
bradediger
Thu Sep 03 14:21:43 -0700 2009
| link
For bystanders: This was pulled into master as Document#group_on_page (in b734c03) and is roadmapped for 0.6. It does not group images or other elements that do not trigger a new page by themselves.
-
doc sweep -- cleanup and augment where necessary.
1 comment Created 5 months ago by sandal -
1 comment Created 5 months ago by sijokgrequestxadding :background_color option to :text in table cellreviewxHi
I am creating a request here according to the discussions athttp://groups.google.com/group/prawn-ruby/browse_thread/thread/aef186542b250187
Could anybody give a solution to this?Thanks
skComments
-
6 comments Created 5 months ago by sandalkill off public access to text_options, it makes me a sad pandarequestxComments
Remove Prawn::Document#text_options feature, as it has made me a very sad panda many times. (closed by 9ce5b87)
OK, I didn't see this coming. Is there a replacement for this functionality? Also the documentation at http://prawn.majesticseacreature.com/docs/prawn-core/classes/Prawn/Document/Text.html still lists this as a valid public method.
Later...
RichardAs the giant warning message upon installing Prawn 0.5.0.1 states, it's a pre-release. Therefore the documentation is still based on the official stable release of Prawn (0.4)
There will be no general replacement, though I will add API calls for most of what people will need:
Things like: Document#wrap_mode= and Document#spacing=
But those will only spring into existence when I properly code up Prawn's low level functions to account for them. Right now they don't, and that's why text_options is dangerous.
Incase you don't use the gems:
" Welcome to Prawn, the best pure-Ruby PDF solution ever! This is version 0.5 RC1
Please note that you have downloaded a pre-release candidate gem, which has some bugs, ugly spots, other bad things in it. This gem is also not fully backwards compatible, and may break existing code.
If you wish to revert until a stable release is ready, uninstall prawn 0.5.0, prawn-core 0.5.0, prawn-layout 0.2.0 and prawn-format 0.2.0
For details on what has changed, see:
http://prawn.majesticseacreature.com/notes/0.5If you have questions, contact us at:
http://groups.google.com/group/prawn-rubyTo submit a patch or report a bug:
http://github.com/sandal/prawnPrawn is meant for experienced Ruby hackers, so if you are new to Ruby, you might want to wait until you've had some practice with the language before expecting Prawn to work for you. Things may change after 1.0, but for now if you're not ready to read source code and patch bugs or missing features yourself (with our help), Prawn might not be the right fit.
But if you know what you're getting yourself into, enjoy! "
Yup, I don't use the Gems so I completely missed this message. Thanks for bringing me up to speed. :)
Yeah, sorry... I had merged in to stable branch early because I anticipated 0.5.1 to come much earlier. Generally, if you track stable moving forward you won't be burned by pre-releases.
For now, lock to a 0.4 tag until you hear about an official 0.5.1 release if the turbulence is causing problems.
FWIW, with regards to text_options() you should have a suitable replacement for all the functionality it offers by Prawn 0.6, no guarantees about 0.5 though.
-
Trying to keep my images in a vector format so that printing and scaling of the prawn generated document stays crisp and lightweight. Would love to be able to embed either EPS or PDF vector art into my prawn generated document.
Comments
I agree, but it is unlikely that I'll have time to work on this soon. I need to focus on stabilizing the existing codebase. I would accept a non-invasive patch for this though, of course.
-
(Note: I've replaced this ticket with a different description --greg)
See http://github.com/rogergl/prawn/commit/5f11d7701e9b63c62d6b7ad3922a3029740f2344 for a reference implementation, but we really should centralize our alignment hackery so we don't repeat this same basic procedure again and again
Comments
-
It seems that font.width_of was changed to font.compute_width_of
Comments
The documentation on the website still refers to Prawn 0.4, as Prawn 0.5.0.1 is a pre-release. In Prawn 0.5, the preferred method will be document.width_of (though it it is correct that this just calls compute_width_of, you should use the former), I'll make a note of that.
-
Table breaks with non-standard leading (:spacing)
3 comments Created 6 months ago by tntHello
As I already reported in a ticket on prawn.lighthouseapp.com/ (URL: http://is.gd/1bGe3 ) for 0.4 in 0.5.1 remains a bug with table cells and a :leading greater than 0. In particular the bug is in prawn/document/text/wrapping.rb and does probably not only concern tables.
A sample script that produces the misbehavior is here: https://prawn.lighthouseapp.com/attachments/128185/prawntest.rb
I fixed it for me in the following way (diff for wrapping.rb):
22c22,23 < string.lines.to_a.length * font.height_at(size) --- > lcount = string.lines.to_a.length > lcount * font.height_at(size) + ( lcount - 1 ) * text_options[:spacing].to_fSo long, T.
Comments
Yeah, that looks like it might work, I'll give it a try. Thanks!
But please note that I plan to kill off public access to text_options, so in the future, you'd probably do something like table data, :leading => ...
-
Allow :margins => [a,b,c,d] or even :margins => k
Comments
Added a :margin option:
http://github.com/henrik/prawn/commit/bdf3e6580288389b7c2404ae040b607b5649b260I suppose I could add in support for [a,b,c,d]. Is there a conventional order? In CSS it's top, right, bottom, left. Same here?
Okay, pushed to my master. Both Document#initialize and Document#start_new_page now support :margin, and it can take anything from a single value to four values:
# The :margin can also be an array much like CSS shorthand: # # # Top and bottom are 20, left and right are 100. # :margin => [20, 100] # # Top is 50, left and right are 100, bottom is 20. # :margin => [50, 100, 20] # # Top is 10, right is 20, bottom is 30, left is 40. # :margin => [10, 20, 30, 40]So fetch me and e.g.
git cherry-pick <a href="/sandal/prawn/commit/2bab3fc76ecdadfae1e858d422530aa10f955f4c">2bab3fc</a>^^ git cherry-pick <a href="/sandal/prawn/commit/2bab3fc76ecdadfae1e858d422530aa10f955f4c">2bab3fc</a>^ git cherry-pick <a href="/sandal/prawn/commit/2bab3fc76ecdadfae1e858d422530aa10f955f4c">2bab3fc</a>to get the commits. Or just merge. I rebased sandal/master, so my commits are on top of it.
-
Ghostscript and ImageMagick need \n after %%EOF
1 comment Created 7 months ago by bradedigerImageMagick (and reportedly Ghostscript) doesn't like Prawn's EOF syntax. I don't believe the particular file in question is relevant -- any PDF from Prawn spits out this error:
$ convert --version Version: ImageMagick 6.5.1-0 2009-05-23 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC $ convert -quality 100 out/0000.pdf out/0000.jpg **** This file has a corrupted %%EOF marker, or garbage after the %%EOF. **** The file was produced by Prawn: **** please notify the author of this software **** that the file does not conform to Adobe's published PDF **** specification. Processing of the file will continue normally.Of course, this is a lie; the file is in compliance with the Adobe spec, but ImageMagick expected a newline after the %%EOF marker. Adding the newline silences that warning. According to the PDF spec (reference 1.3, appendix H, implementation note 15), Adobe readers accept %%EOF anywhere in the last 1024 bytes of the file.
Patched at bradediger/prawn@f8f5257. Hopefully patches are accepted to make my life easier on busted unsupported viewers.
Comments
-
1 comment Created 7 months ago by sandalbring 'supported viewers' document onto wiki and put link on prawn webpagerequestxComments
bradediger
Mon Nov 09 13:15:00 -0800 2009
| link
Added to wiki at http://wiki.github.com/sandal/prawn/supported-pdf-viewers.
> -
column_box doesn't flow between columns when displaying tables instead of text
3 comments Created 8 months ago by rnhurtWhile trying to work with column_box I found out that plain text works well but tables don't flow properly.
This works fine:
column_box [0,cursor], :width => bounds.width, :columns => 2 do text " This is a test " * 100 endThis just causes the tables to continue in the first column over multiple pages, never flowing into the second column:
column_box [0,cursor], :width => bounds.width, :columns => 2 do table data, :headers => headers, :header_color => 'C0C0C0', :font_size => 7, :border_style => :grid, :border_width => 0.5, :width => bounds.width-10 endComments
This is a prawn-layout issue (maybe), please re-file there.
Thanks!
I think this issue may be related to the fact that tables cannot be used in a bounding box without a height, something I hope to fix eventually. But even if it's not related, its worth knowing about. I want to keep prawn-core independent of the table code though, which is why I asked you to move it over there.
-
Documentation for specifying non-standard page sizes
0 comments Created 8 months ago by zubinNeed to add documentation for cases where non-standard page size is required (ie not included in Document::PageGeometry::SIZES):
Use [width, height] instead of a symbol. (In PDF points 1/72 in)
Comments
-
5 comments Created 8 months ago by sandalMake bounding_box fully enclose nested elementsrequestxAs per Greg's request in the following mailing list post, here's a feature request: http://groups.google.com/group/prawn-ruby/browse_thread/thread/229740129eb9a506
The behaviour of bounding_box should be changed to fully enclose nested elements, such that Prawn elements that follow a bounding box containing multiple nested elements with varying heights will align with the bottom edge of the bounding_box, and not the bottom edge of the last rendered nested element. This should obviously only be the case if the following element uses 'cursor' to denote it's y-axis alignment.
I hope I've elucidated adequately.
Samå
Comments
Any news on this?
I'm having this same issue, now sure how to fix it for now.
no news. I may get this in for 0.5, if not, definitely 0.6
I'm sure a lot of people would love to see it sooner of course :)
This would include me :)
In either case, thanks in advance!It will be in when it's ready. Please don't post vacuous comments.
-
https://prawn.lighthouseapp.com/attachments/61121/interlaced.png
Here's a sample image Prawn chokes on. This is your dice.png. I just reopened it in Photoshop and resaved it with the interlaced setting on. Prawn now chokes on parsing it, reporting the wrong error mid-parse.
In addition, see the discussion at:
https://prawn.lighthouseapp.com/projects/9398-prawn/tickets/82-adding-a-png-to-a-pdf-appears-corruptedComments
one way to fix this is to extend the scope of prawn-fast-png to handle all png settings, not only the alpha channel extraction.
Yes, that would address at least some of these issues. But then maybe prawn-fast-png would need a more general name... prawn-png-improved ?
Anyway, that's a question for Wojtek, not me. So feel free to contact him if you want to see if he's interested.
I've fixed this in my png_fixes branch, plus add some new specs
wpiekutowski
Fri Apr 24 01:49:46 -0700 2009
| link
I was thinking about delegating all PNG handling to RMagick. That would probably give compatibility with any PNG format out there. In that case a name change may be appropriate somewhere in the future. I think it shouldn't be too complicated to rewrite prawn/images/png.rb with RMagick. Unfortunately I'm kind of busy currently and I can't pursue this on my own. Probably in May I'll have more time to try this approach.
I'd imagine replacing Prawn::Images::PNG with a RMagick based version shouldn't be too hard. It's not like it does much.
I'm not sure how Greg feels, but I think that'd be great as an optional prawn plugin. I'd be keen to keep mainline prawn pure ruby if possible. I use c extensions in projects, but sometimes it's nice to be able to weight up the various pros and cons.
ie. faster and more format support vs. possible memory issues and reduced platform compatibility.
wpiekutowski
Fri Apr 24 02:37:07 -0700 2009
| link
By 'rewrite prawn/images/png.rb with RMagick' I meant to monkey patch Prawn::Images::PNG though a separate gem, like now prawn-fast-png deals with alpha channel separation performance.
yeah, right on, a RMagick based Prawn PNG is a good workaround for our bottleneck, but should be done as an extension gem.
Let us know when you have something.
-
It would be very convenient to a project I'm doing if it were possibly to do, e.g.
pdf.cell blahblah, :vertical_align => :center
and have that work as easily as :horizontal_align => :center does. You can "fake it" with vertical padding fairly easily... right until you end up word wrapping.
I'm currently banging my head against this for my project but if I get a generalizable solution working I'll try getting you guys the code.
Comments
-
In PDF::Writer I could set the document properties "author", "title", "keywords", "subject", "creator", "producer".
(It's been my experience that these help with SEO.)
Comments
-
3 comments Created 8 months ago by sandal1.0xpdf-writerxTweak Document#text_box to implement some features from PDF::Writer#add_text_wraprequestxThis is a request for several enhancements to Prawn#text_box so that it would support the features of #add_text_wrap in PDF::Writer.
When Prawn#text_box is called with the :truncate or :ellipses option the text which is not displayed in the text box is returned. (Implemented by geeksam and merged for 0.6)
When Prawn#text_box is called with the :angle => (int in range 0..259) option, the text is rotated as it would be using PDF::Writer #add_text_wrap
When Prawn#text_box is called with the :justification => :left | :center option, the text is justified as it would be using PDF::Writer #add_text_wrap
Comments
-
Testing this new issues hotness
Comments





Can you give me an example that runs standalone outside of rails with no additional external code needed? If you have a particular font you're using, upload it somewhere so I can run your code.
Also, use a supported viewer before reporting bugs:
http://wiki.github.com/sandal/prawn/supported-pdf-viewers
Neither KGhost nor Acrobat 8 are supported.
I closed the ticket because right now it's not possible to reproduce the issue given the information you've provided, but once you update it, feel free to re-open.
Okey, I think it has something to do with image, when I opened it in gimp and saved again, it worked fine (it was png image)
I'll try to prepare test pack, right now I've managed to fix it +-, but now image has wrong size (it's bigger then it should be), is :height attribute for #image given in pixels or something else? (image is to big even when no :height or :width is passed)
height and width are given in 1/72 in (default point size for PDF), your image size is going to depend on the DPI the image was saved at. See the Prawn mailing list for extensive discussions on this.
Hmmm this issue tracker doesn't allow attaching files so here : http://rapidshare.com/files/330230482/problematic_image.rar
This provides 2 images, original one I've tested this on, and one that I've simply opened/saved in gimp. First one fails, second one works, btw, I've saved second one in 72dpi, and it's still displaing to big.
Please read the discussions about this on the mailing list. It's unrelated to your original issue and has come up many times before. Also, in the future, please use an open zip format, such as .gz or .bz2
I've attached a packet with original image that is causing problem I've described in original ticket. So it's still not resolved. Image size problem is just a side thing.
The issue sounds to be with your image, though. Please move this discussion to the mailing list so someone can help you. This isn't a bug until it can be reproduced in one of the supported viewers.
That's why I've attached a package with both images and ruby test case, so you can try and reproduce it. Thanks for your help so far. I'm doing it for free for an OS project, and I guess I'll just leave comment that users that want to put their own logo in will have to check if it displays correctly and if size is okey.
We are all volunteers here, keep that in mind. You can take a few extra minutes to test in a supported viewer and then send us a package we can open without special software (such as a bz2 or gz), or you can post this to the mailing list so that someone can help you with your support request.
We welcome both kind of discussions, but the bug tracker is for bugs.