On 2021-07-27 12:56:10, Mehmet ERİBOL wrote:
> I am looking for span documentations but could not find any. Is there
> a way to make span for table cell?

This is unfortunately not supported yet, though I definitely want to add
that in the future.

/Robin

Hi Mehmet,

On 2021-07-27 12:59:51, Mehmet ERİBOL wrote:
> I am working with tables. An a table cell can be multi line but it is
> automatic. I tried add multi element for creating new paragrah but
> row.push_element() only works for one element. I used "\n" formatting
> but it just does not affect what i want.
> 
> Is there a way to make new line for one string?

I think this should work by creating a LinearLayout and then adding
multiple paragraphs to that layout.  Directly supporting \n in
paragraphs is planned but not yet implemented.

Hi Mehmet,

On 2021-07-24 20:47:17, Mehmet ERİBOL wrote:
> I am not sure if it is the same problem. My problem is, my example
> wrok nice with english character. But when i add turkish special
> character(like şÇöÖüÜİı) browser can not render the pdf.

This should work fine.  But note that there are two types of fonts in
PDF:  built-in and embedded.  Built-in fonts only support the
Windows-1252 character set which does not contain the Turkish
characters.  To use UTF-8 strings, you have to embed the font into the
PDF file.  This means that you have to set the second argument for
FontData::load to None.

On 2021-07-22 03:47:43, eribol@libredu.org wrote:
> My problem is, i am using creating pdf for my wasm project. So, there
> is no filesystem. I can download the ttf's files from my server but i
> don't know how to use it with from_files() method. Is there any way to
> use fonts without filesystem?

Yes.  The fonts::from_files function is just a shorthand for calling
FontData::load for all four font styles.  Instead of FontData::load
(which takes a path), you can use FontData::new (which takes the raw
font data).  So this gives you two options:  Either you include the font
data in your binary using include_bytes!, or you download the font from
the network.  You can then manually construct a FontFamily instance
using FontData::new.

On 2021-07-09 00:57:38, Daniel Mueller wrote:
> FYI, it seems as if there is now official guidance on the matter, see this
> update: https://github.com/rust-lang/project-error-handling/issues/27 (which
> I read as being in-line with what we have decided on).
> 
> Also, Rust by Example has merged the corresponding pull request:
> https://github.com/rust-lang/rust-by-example/pull/1375

Thanks for the pointer!  I’m glad this is finally about to be settled
because I also noticed this issue with other libraries.

/Robin

I’ve experimented a bit with possible solutions both for the case where
a long string cannot be fitted into a line and for the wrong word
splitting for Chinese text.  It is not entirely trivial to fix these
with the current wrapping system.  I’d rather not do that work right now
as we are migrating to textwrap soon, which will fix both issues.

My current plan is to finish the textwrap migration after the next
release v0.3.0.  I hope this is acceptable for you.

/Robin

On 2021-06-21 19:17:00, Allen Wyma wrote:
> thanks for the detailed message: basically for chinese, you can break
> after each character is fine. There's no concept of "words", just
> characters. Although a word like telephone is written as 電話, it's okay
> to break after 電 because seeing the character 話 afterwards makes it
> clear that they belong together.

Thanks for the explanation!  So the problem is my naive approach of
splitting words at spaces.  The proper solution would be to use the
Unicode word splitting algorithm, but I’ll have to do some research on
how to properly apply that.  I have some other tasks that I want to
finish fist.

In the mean time, may I suggest the following workaround:  If a

On 2021-06-21 18:53:57, Allen Wyma wrote:
> to follow up: any ideas on how to do the text wrapping? or even a work
> around? Seems kind of strange that there's 0 text instead of say the
> text just traveling off the page?

There seems to be a bug because usually genpdf returns an error if the
content does not fit on the page.  Just breaking the string at some
arbitrary point might be a better solution, but I haven’t implemented
that yet.  I’ve created some tickets for that:
	https://todo.sr.ht/~ireas/genpdf-rs/54
	https://todo.sr.ht/~ireas/genpdf-rs/55
	https://todo.sr.ht/~ireas/genpdf-rs/56

Currently the wrapping logic is something like this:  First, split the

Hi Allen,

I think I found the reason why your example doesn’t work:
	https://gist.github.com/HangingClowns/bed7737f5886f0660a001343f574adda#file-main-rs-L20
Uncomment that line and it print the signs.  (There seems to be another
issue if the string is too long and can’t be split up using the naive
implementation – please try shorter strings first.)

/Robin

Hi Allen,

I think there are two different aspects:

One aspect is using characters from non-Latin scripts.  This should
already work.  I’ll try to investigate why the characters are missing in
your example.

The other aspect is proper i18n that takes into account the writing
direction and other language-specific properties.  This is currently not
implemented in genpdf (other than hyphenation).  I’m happy to accept
patches that improve this, but it is not on my roadmap to implement that
myself in the near future.