Japanese build in PDF fonts with prawn?
Cosinus
I love so much the feature in prawn to handle font encoding and I can
embed TTF fonts. Just wonder somebody here has got Japanese (standard)
font (not embedded TTF) running with prawn.
Western font can be directly be used, but with Asian fonts (Japan/
China/Korea) having huge fonts it would be nice to use build-in
fonts.
( http://www.adobe.com/products/acrobat/acrrasianfontpack.html )
Cheers,
Thomas
Gregory Brown
> Western font can be directly be used, but with Asian fonts (Japan/
> China/Korea) having huge fonts it would be nice to use build-in
> fonts.
> ( http://www.adobe.com/products/acrobat/acrrasianfontpack.html )
As far as I know, this is a vendor-specific feature. The PDF spec
only specifies a very small set of latin fonts.
Luckily, we support subsetting in Prawn so only the characters you use
will be embedded. That will hopefully keep your file sizes
manageable.
-greg
Cosinus
was playing with Japanese font and some across a problem with center
alignment (looks like it effects all kind of text, not only Japanese).
I'm using the gem packages and maybe this is fixed in git....
I debugged it and found in file prawn/document/text.rb (method
wrapped_text)
-----
lines.each_with_index do |e,i|
move_text_position(font.ascender)
e.gsub!(/\n/,"") <-- I added this
line
line_width = width_of(e, :kerning => options[:kerning])
----
I added this "e.gsub..." line for testing.
The problem is that the lines end with a "\n" character in this coding
(don't know why this is added).
However the "width_of" function is returning the with including this
"\n"! I didn't expected that "\n" has a with but with this TrueType
font it has a with of 12pt (as I use 12pt Japanese Mincho).
In the later processioning the line is calculated as one character
longer that it actually is and the text is set incorrectly.
I removed the "\n" character for test purpose and this fixed the
problem for me.
Cheers,
Thomas
On 12 Aug., 03:16, Gregory Brown <gregory.t.br...@gmail.com> wrote:
Cosinus
just as a workaround for this bug (until this gets fixed in official
release).
Just inserting belows coding after requireing Prawn:
-----
module Prawn
class Document
alias_method :orig_width_of, :width_of
def width_of(string, options={})
orig_width_of(string.gsub(/\n\z/,""),options)
end
end
end
-----
this is simply overwriting Prawn's width_of method by a version that
is deleting all "\n" characters at the end of the string.
I would like to attach PDF's showing the difference, but google-groups
seems to have no attachment.
In my test case I just display text in a simple bounding_box
(character mode):
----
bounding_box([text_x,text_y - text_offset -
text_font_offset], :width => text_width, :height => text_height) do
text text_cut, :align => :center, :mode => text_wrap
end
----
I'm using Japanese ume-font set:
http://sourceforge.jp/projects/ume-font/releases/22212
(Mincho font)
BTW: I love the the this wonderful prawn documentation:
http://github.com/sandal/prawn/blob/656ef4d88bf30cec3ebbbcdcc133cee27ef9948c/manual/src/index.txt
Just there is a minor mistake: the "wrap mode" parameter for the
"text" command is called ":wrap" in the documentation but ":mode" in
the gem release.
Looks like documentation or gem-released version is outdated. :-)
Thanks a lot the nice prawn tool and your help so far!
Cheers,
Thomas
Gregory Brown
> I would like to attach PDF's showing the difference, but google-groups
> seems to have no attachment.
You can send one via email to:
prawn...@googlegroups.com
> BTW: I love the the this wonderful prawn documentation:
> http://github.com/sandal/prawn/blob/656ef4d88bf30cec3ebbbcdcc133cee27ef9948c/manual/src/index.txt
>
> Just there is a minor mistake: the "wrap mode" parameter for the
> "text" command is called ":wrap" in the documentation but ":mode" in
> the gem release.
> Looks like documentation or gem-released version is outdated. :-)
Yep, that documentation was never officially released but will be
spruced up as part of Duke Nukem Fore....
Prawn 0.5.1
Cosinus
:-) I never comment my programming as this destroys the beauty or my
coding :-)
Thanks so much for your follow-up always and as I just come about
another issue I hope you don't mind I raise this:
I have western and Japanese test in one document and as I just learned
it's difficult to find a font that is actually supporting both,...
means if I use a Japanese font the wester text looks really ugly and a
western font is usually missing the Japanese glyphs is need.
Finally I hope I found this nice one:
http://en.wikipedia.org/wiki/Droid_%28font%29
I liked to try ("Droid Sans Fallback") but prawn is raising the
exception:
"no unicode cmap for font"
Backtrace:
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
174:in `cmap'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
213:in `character_width_by_code'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
38:in `compute_width_of'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.3/lib/active_record/
attribute_methods.rb:211:in `inject'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
37:in `each'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
37:in `inject'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font/ttf.rb:
37:in `compute_width_of'
/usr/lib/ruby/gems/1.8/gems/prawn-core-0.5.0.1/lib/prawn/font.rb:
194:in `orig_width_of'
[...]
Have not checked the details, but I assume that this exception means
only unicode cmap TTF tables are currently supported?
(guess this font is e.g. JIS encoded cmap)
Is there any plan to support this?
Sorry for bothering again.
Cheers,
Thomas
On 21 Aug., 20:13, Gregory Brown <gregory.t.br...@gmail.com> wrote:
> > I would like to attach PDF's showing the difference, but google-groups
> > seems to have no attachment.
>
> You can send one via email to:
> prawn...@googlegroups.com
>
> > BTW: I love the the this wonderful prawn documentation:
Gregory Brown
>
> I liked to try ("Droid Sans Fallback") but prawn is raising the
> exception:
> "no unicode cmap for font"
> Have not checked the details, but I assume that this exception means
> only unicode cmap TTF tables are currently supported?
> (guess this font is e.g. JIS encoded cmap)
> Is there any plan to support this?
I would accept a patch if it did not break backwards compatibility.
But currently, the approach with Prawn is to target UTF-8. It'll
transcode automatically for you on Ruby 1.9, but under the hood, it's
all UTF-8 so we don't look for other cmaps in fonts.
-greg
Cosinus
take a little (everybody is invited to jump in)
Changes should go into ttfunk. Correct?
Just to keep a record for myself:
1) I checked the cmap with ttx:
[..]
<cmap_format_12 platformID="3" platEncID="10" format="12" reserved="0"
length="43192" language="0" nGroups="3598">
[..]
Result: This font is 32 unicode, but praw currently just support the
16 Bit unicode version.
Method "unicode" in:
http://github.com/sandal/ttfunk/blob/900032abee9272485e77f6b68e87c9ad6346f69b/lib/ttfunk/table/cmap/subtable.rb
main problem: cmap is encoded in format 12 (but only 4 and 0 supported
at the moment by ttfunk).
On 23 Aug., 03:44, Gregory Brown <gregory.t.br...@gmail.com> wrote:
Gregory Brown
>
> I see... i'll have a look but I'm currently short in time so it'll
> take a little (everybody is invited to jump in)
> Changes should go into ttfunk. Correct?
That's correct. You might want to dump these details onto a ticket in
the Github issues tracker there. Easier to find that way.
Cosinus
issue created and patch provided in issue:
http://github.com/sandal/ttfunk/issues/#issue/1
As I'm not a github user I hope this is ok this way.
Thanks,
Thomas
On 23 Aug., 21:45, Gregory Brown <gregory.t.br...@gmail.com> wrote:
Gregory Brown
>
> Dear Greg,
> issue created and patch provided in issue:
> http://github.com/sandal/ttfunk/issues/#issue/1
> As I'm not a github user I hope this is ok this way.
you don't need to sign up for github, but you really should use git
format-patch instead of diff. This is to retain your authorship.
Go ahead and update the ticket when you have a git formatted patch,
and I'll pull it in. Code looks fine.
-greg