ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-744016761
@cbmarcum thank you for the detailed review.
I don't know Korean, unfortunately, but from this page:
https://fonts.google.com/?subset=korean=%ED%95%98_type=custom
it
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-711165338
> The file provided in PR #106 ([this
one](https://github.com/apache/openoffice/files/5390104/crashing-with-noto-serif-cjk-jp.docx))
is rendered incorrectly as PDF.
> I am
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-709985252
The file provided in PR #106 ([this
one](https://github.com/apache/openoffice/files/5390104/crashing-with-noto-serif-cjk-jp.docx))
is rendered incorrectly as PDF.
I am working
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-705172239
I apologize for taking so long to reply.
[This file](https://github.com/apache/openoffice/files/5343566/pr89.zip)
contains an ODT and a PDF that was generated with the
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-695216559
I forgot to mention that while developing this PR, I made some mistakes that
produced _invalid output_ with no crashes. The PDF was wrong (garbled
characters) but no error
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-695215925
> A good test is after apply that the Font still works as expected. The
patch first was a quick and dirty fix, and this should be the proper one.
Are there any automated
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-662862458
> Thanks for the feedback. I think the patch is then feature complete.
> To have one commit that can be simple be merged would be nice. Please do
the merge.
Done.
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-662696345
I started to dig a bit deeper into CFF and Type2, then I understood they are
out of my reach.
In the end, if the code works well as it is, I would refrain to change it
any
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-657786860
I am trying to get a grasp on the CFF concepts. It's... a whole world. Thank
you @leginee for the pointers!
However it will take me some more time to understand if it is
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-652807797
Thank you, Petko. It would help me to know what is the expected average size
and variation of such stacks, to give a "meaningful" initial size and optimize
the number of calls to
ardovm commented on pull request #89:
URL: https://github.com/apache/openoffice/pull/89#issuecomment-652464308
I see that in the same file there are other fixed-size arrays used as stacks
(if I understand correctly):
* `CffSubsetterContext::mnValStack`,
*
11 matches
Mail list logo