| | <<<Back 1 day (to 2017/08/11) | 20170812 |
| sebras | tor8 (for the logs): so opengroup states about the + flag: The result of a signed conversion shall always begin with a sign ( '+' or '-' ). The conversion shall begin with a sign only when a negative value is converted if this flag is not specified. | 06:30.33 |
| | tor8: so the question is whether the value can even be negative in this case. | 06:31.08 |
| | tor8: about 'x' the spec states: The unsigned argument shall be converted to unsigned hexadecimal format in the style "dddd"; the letters "abcdef" are used. The precision specifies the minimum number of digits to appear; if the value being converted can be represented in fewer digits, it shall be expanded with leading zeros. The default precision is 1. The result of converting zero with an explicit | 06:31.33 |
| | precision of zero shall be no characters. | 06:31.39 |
| | so for 'x' the value is always unsigned and hence never negative, so when the '+' is not given then no sign should be printed. | 06:33.31 |
| | if the '+' _is_ given however the question is whether the 'x' is a _signed conversion_, my bet is that is not because the value is unsigned. | 06:34.30 |
| | I also tested the following code: | 06:35.14 |
| | printf("%%d:%d:%d:%%+d:%+d:%+d:%%u:%u:%u:%%+u:%+u:%+u:\n", 9, -9, 9, -9, 9, -9, 9, -9, 9, -9); | 06:35.19 |
| | using gcc: %d:9:-9:%+d:+9:-9:%u:9:4294967287:%+u:9:4294967287: | 06:35.27 |
| | and clang: %d:9:-9:%+d:+9:-9:%u:9:4294967287:%+u:9:4294967287: | 06:35.32 |
| | it should be noted that clang complains about %+u being used: warning: flag '+' results in undefined behavior with 'u' conversion specifier | 06:36.44 |
| | though it seems that both compiles treat this format string the same: i.e. no sign is printed. | 06:37.04 |
| Guest28238 | Hello. Is this the place to ask questions about mupdf? | 08:22.33 |
| | Development questions? | 08:22.55 |
| sebras | Guest28238 (for the logs): yes, you are in the right location. | 08:46.45 |
| Guest26768 | Hi sebras, I'm using mupdflib on Visual Studio 2015, windows 10 64 bits. | 10:22.00 |
| | I'm trying to compile https://mupdf.com/docs/examples/example.c on Debug/32 bits | 10:22.25 |
| | but it keeps showing SeverityCodeDescriptionProjectFileLineSuppression State ErrorLNK2001unresolved external symbol _fz_resources_fonts_han_SourceHanSansCN_Regular_otfConsoleApplication1C:\Users\Bruno\Desktop\mulite\ConsoleApplication1\libmupdf.lib(noto.obj) 1 | 10:22.57 |
| | and 247 similar unresolved external link error | 10:23.34 |
| | I'm linking with libmupdf.lib;libthirdparty.lib;libglfw.lib; | 10:24.22 |
| sebras | Guest26768: hi let me read the logs for a bit. | 10:49.28 |
| | Guest26768: aha, I think I know what the problem is. there is a script that generates/convertes mupdf's builtin fonts as C-files. | 10:51.36 |
| | Guest26768: if you look into platform/win32/generated.vcproj you will see that there it uses a script called generate.bat | 10:51.53 |
| | Guest26768: this needs to be run to place place these fonts as C-files in a directory called generated in the top-level build directory. | 10:52.29 |
| | Guest26768: did you do that step? | 10:52.52 |
| Guest26768 | No, I did not know about this step | 11:10.29 |
| sebras | Guest26768: alright, see if running generate.bat helps you. | 11:13.28 |
| | Guest26768: I think, maybe if you just build platform/win32/generated.vcproj once you will be able to build the example code. | 11:14.10 |
| | Guest26768: btw, what are you planning to use mupdf for? are you doing your own viewer based on mupdf? | 11:14.38 |
| Guest26768 | Hi sebras, I did not solved. What worked was compilng libfonts and linking my project with libfonts.lib. | 11:27.26 |
| | **Hi sebras, It did not solved | 11:27.43 |
| | In fact, there are no project on debug mode for libfonts | 11:28.52 |
| | I linked with the release mode | 11:29.01 |
| sebras | Guest26768: what is libfonts.lib? this doesn't be anything that mupdf distributes and the unresolved symbol you mentioned indeed references fz_resources, so I'm a little puzzled. | 11:43.47 |
| | Guest26768: just because I'm curious, are you developing your own viewer based on mupdf? | 11:44.09 |
| Guest26768 | No, I'm trying to split a pdf with multiple pages into several pdfs with one page | 11:55.16 |
| | There is a project called libfonts on mupdf Visual Studio solution file at \mupdf-1.11-source\platform\win32\libfonts.vcproj | 11:57.28 |
| sebras | Guest26768: oh, I see, libfonts.vcproj has been renamed in the git repository, so I couldn't find it. sorry. :) | 12:08.10 |
| | Guest26768: if you are able to script it you can extract a single like so: mutool convert -o page7.pdf multiple-pages.pdf 7 | 12:12.52 |
| | Guest26768: and you can use mutool info multiple-pages.pdf to find out how many pages there are. | 12:13.39 |
| Guest___ | Hi sebras, it worked, but the output files are bigger than the original. I ran mutool clean -gggg -f -i -s page0.pdf page0a.pdf, but it did not compress it. | 12:31.34 |
| | I used the -z option, but it is still bigger | 12:32.55 |
| | The original file has 151KB and 3 pages. The mutool convert extract the first page using 327KB. Using mutool clean reduced to 217KB | 12:34.57 |
| sebras | malc_: saw your mail, haven't had time to respond yet. | 12:42.59 |
| | Guest___: try mutool convert -O compress -o page7.pdf multiple-pages.pdf 7 | 12:43.44 |
| Guest___ | It still has 218KB. Auditing the space usage, I see that there is 170KB of fonts embedded on the pdf file that the original file does not has. | 12:47.01 |
| | Thus, it appears that mutool is embedding unnecessary fonts | 12:47.34 |
| sebras | Guest___: that seems weird. if you are able to provide the original document and exact command line you used when the unnecessary fonts appeared, please report this as a bug at bugs.ghostscript.com | 12:49.01 |
| | malc_: so in the draft e-mail that I haven't sent yet, I'm writing that I added while trying to remove usage of malloc from thirdparty libraries. | 12:49.47 |
| | malc_: as mupdf itself doesn't normally refer to the fonts on the system I never noticed the issue you llppers discovered. | 12:50.37 |
| malc_ | sebras: i see | 12:50.50 |
| sebras | malc_: so from my perspective it was not a security issue. | 12:51.03 |
| malc_ | sebras: what's alarming is that i had to do a git clean -dfx inside mupdf to hit the issue, wasn't reproducible otherwise | 12:51.49 |
| | IOW make blows | 12:51.58 |
| sebras | malc_: I guess that highlights that there is a dependency missing in our makefiles perhaps. | 12:52.41 |
| malc_ | sebras: most likely | 12:52.51 |
| sebras | malc_: I | 12:52.54 |
| | malc_: 'll bring both issues up with tor8 when he's back. I can't commit things now, without having people review it. | 12:53.23 |
| malc_ | sebras: sure | 12:53.37 |
| sebras | malc_: also what is the 8c51891f commit that tuncer mentioned? it's neither in mupdf, nor in llpp...? | 12:54.02 |
| malc_ | sebras: no idea TBH | 12:54.40 |
| sebras | malc_: ok, so the next commit after the one that causes trouble sets the custom allocator for freetype. apparently we have never used that before... | 12:56.32 |
| malc_ | sebras: EINVAL be it in POSIX or FreeType is one of the most unhelpful things ever to be invented... something went wrong.. and we are telling you, so go abort your program | 12:57.14 |
| sebras | malc_: I think it was meant to detect invalid arguments to a function, but has since been extended to other meanings. | 12:59.23 |
| sebras | foods. | 12:59.34 |
| sebras | is back. | 13:35.19 |
| malc_ | sebras: #0 FT_Stream_New (library=0x100283040, args=0x7fffffffe5e0, astream=0x7fffffffe | 13:42.04 |
| | 548) at thirdparty/freetype/src/base/ftobjs.c:218 | 13:42.04 |
| | #1 0x0000000100007fab in FT_Open_Face (library=0x100283040, args=0x7fffffffe5e0 | 13:42.04 |
| | , face_index=0, aface=0x7fffffffe658) at thirdparty/freetype/src/base/ftobjs.c:2 | 13:42.04 |
| | 116 | 13:42.07 |
| | #2 0x0000000100007e3d in FT_New_Face (library=0x100283040, pathname=0x7fffffffe | 13:42.10 |
| | a78 "/home/malc/tmp/c/font", face_index=0, aface=0x7fffffffe658) at thirdparty/f | 13:42.14 |
| | reetype/src/base/ftobjs.c:1240 | 13:42.17 |
| | #3 0x0000000100004227 in main (argc=1, argv=0x7fffffffe758) at font.c:15 | 13:42.20 |
| | | 13:42.23 |
| | sebras: 187 if ( args->flags & FT_OPEN_MEMORY ) | 13:42.38 |
| | (gdb) | 13:42.38 |
| | 216 error = FT_THROW( Invalid_Argument ); | 13:42.38 |
| | (gdb) | 13:42.38 |
| | 218 if ( error ) | 13:42.41 |
| | (gdb) p error | 13:42.44 |
| | $7 = 6 | 13:42.47 |
| | | 13:42.51 |
| | so ahem... not sure what to make of that | 13:42.54 |
| sebras | malc_: you are to make of that the flags indicate that the typeface is not a memory buffer I guess and then streaming from the file system is disabled after which there are not option but to fail. | 13:47.38 |
| | malc_: why did they coose Invalid_Argument? I have no idea. | 13:47.48 |
| | malc_: also Invalid_Argument appears to be freetypes own error code, and so actually unrelated to POSIX' EINVAL. | 13:49.20 |
| malc_ | sebras: I know that they are unrelated, i was just saying that both are equally idiotic | 14:17.39 |
| | 1/0 okay/error carries only marginally less information with it | 14:18.24 |
| | also: | 14:21.39 |
| | $ gcc -o font font.c -I ~/xsrc/llpp/mupdf/thirdparty/freetype/include ~/xsrc/llpp/mupdf/build/debug/libmupdfthird.a -lm | 14:21.40 |
| | $ ./font ~/x/rcs/git/mupdf/resources/fonts/droid/DroidSansFallback.ttf | 14:21.40 |
| | font: FT_New_Face(./font): 6 | 14:21.40 |
| | $ gcc -g -o font font.c $(pkg-config --cflags --libs freetype2) | 14:21.43 |
| | $ ./font ~/x/rcs/git/mupdf/resources/fonts/droid/DroidSansFallback.ttf | 14:21.46 |
| | font: FT_New_Face(./font): 2 | 14:21.49 |
| | | 14:21.53 |
| | FT_ERRORDEF_( Unknown_File_Format, 0x02, | 14:22.30 |
| | color me confused | 14:22.38 |
| sebras | malc_: the latter seems quite mysterious to me. | 15:13.16 |
| malc_ | sebras: and https://en.wikipedia.org/wiki/The_Guide_for_the_Perplexed doesn't help, bummer | 15:14.35 |
| Guest___ | Hi sebras, I have another question. I am trying to make a png2pdf procedure, as follows: | 15:19.02 |
| | fz_context *ctx = fz_new_context(NULL, NULL, FZ_STORE_UNLIMITED); | 15:19.30 |
| | fz_register_document_handlers(ctx); | 15:19.40 |
| | fz_image *image = fz_new_image_from_file(ctx, "2012_2.png"); | 15:19.52 |
| | fz_document_writer *out = fz_new_document_writer(ctx, "page0.pdf", "pdf", "compress"); | 15:19.57 |
| | fz_rect mediabox; | 15:20.03 |
| | mediabox.x0 = 0; | 15:20.08 |
| | mediabox.y0 = 0; | 15:20.13 |
| | mediabox.x1 = image->w; | 15:20.17 |
| | mediabox.y1 = image->h; | 15:20.21 |
| | fz_device *dev = fz_begin_page(ctx, out, &mediabox); | 15:20.26 |
| | fz_fill_image(ctx, dev, image, &fz_identity, 1); | 15:20.32 |
| | fz_end_page(ctx, out); | 15:20.37 |
| | fz_close_document_writer(ctx, out); | 15:20.43 |
| | fz_drop_document_writer(ctx, out); | 15:20.47 |
| | fz_drop_image(ctx, image); | 15:20.53 |
| | fz_drop_context(ctx); | 15:20.56 |
| | But the generated pdf is blank. It has the correct mediabox, but no image | 15:21.28 |
| | What am I missing? | 15:21.53 |
| Guest57283 | I updated the code to | 17:10.18 |
| | fz_matrix ctm = *fz_copy_matrix(&ctm, &fz_identity); | 17:10.25 |
| | float xs = image->w * 96.0 / image->xres; | 17:10.30 |
| | float ys = image->h * 96.0 / image->yres; | 17:10.35 |
| | fz_scale(&ctm, xs, ys); | 17:10.40 |
| | fz_rect mediabox = {0, 0, xs, ys}; | 17:10.44 |
| | fz_device *dev = fz_begin_page(ctx, out, &mediabox); | 17:10.49 |
| | fz_fill_image(ctx, dev, image, &ctm, 1); | 17:10.55 |
| | fz_end_page(ctx, out); | 17:11.00 |
| | Now, part of the image shows and very small. | 17:11.15 |
| | How to get the correct dimensions of the image? | 17:11.35 |
| sebras | Guest57283: most developers are here on european daytime mon->fri | 17:35.00 |
| | Guest57283: unless your tinkering with the project has been resolved by then I'm sure someone will be able to help you. :) | 17:35.33 |
| Guest57283 | ok thanks, so I also tried the following | 18:06.50 |
| | fz_image *image = fz_new_image_from_file(ctx, "2012_2.png"); | 18:06.50 |
| | pdf_document* doc = pdf_create_document(ctx); | 18:06.58 |
| | pdf_obj* imgObj = pdf_add_image(ctx, doc, image, 0); | 18:07.03 |
| | pdf_obj* dictObj = pdf_new_dict(ctx, doc, 0); | 18:07.08 |
| | pdf_obj* resources = pdf_add_object_drop(ctx, doc, imgObj); | 18:07.19 |
| | char* data = "10 10 280 330 re s\nq 200 0 0 200 50 100 cm /Im0 Do Q\n"; | 18:07.24 |
| | fz_buffer* contents = fz_new_buffer_from_data(ctx, (unsigned char*)data, strlen(data)); | 18:07.29 |
| | fz_rect mediabox = { 0, 0, image->w, image->h }; | 18:07.34 |
| | pdf_obj* page = pdf_add_page(ctx, doc, &mediabox, 0, resources, contents); | 18:07.39 |
| | pdf_insert_page(ctx, doc, -1, page); | 18:07.43 |
| | const char *options = "compress"; | 18:07.48 |
| | pdf_write_options pwo; | 18:07.52 |
| | pdf_parse_write_options(ctx, &pwo, options); | 18:07.56 |
| | pdf_save_document(ctx, doc, "page1.pdf", &pwo); | 18:08.01 |
| | I'm guessing that my problem is building the dictionary (dictObj) and how to link with /Im0 | 18:08.47 |
| | * and how to link image with /Im0 | 18:09.10 |
| malc_ | sebras: FT_CONFIG_OPTION_DISABLE_STREAM_SUPPORT in scripts/freetype/slimftoptions.h is the culprit | 18:16.39 |
| sebras | malc_: I know. | 19:45.03 |
| | malc_: when we load system fonts we appear to be reading the file ourselves and then feeding it into freetype as a memory buffer. | 19:45.56 |
| | malc_: not yet sure if I should revert the config-define or not. | 19:46.16 |
| | Forward 1 day (to 2017/08/13)>>> | |
Log of #mupdf at irc.freenode.net.