| | <<<Back 1 day (to 2015/11/19) | 20151120 |
| rayjj | just realized that my IRC "chatzilla" was not up | 06:05.45 |
| | I think I have the problem(s) with peeved sorted out. I managed to reboot it and have it come up "hands off" as a regression machine | 06:08.25 |
| | somehow the /etc/network/interfaces got honked up and had "auto lo eth0" as the first line rather than just "auto lo" | 06:09.17 |
| | then the second "auto eth0" (with the actual IP, etc) confused the startup | 06:09.52 |
| mrev1l | hi! um..is it a right place to ask questions about MuPDF? | 09:11.09 |
| kens | Yes | 09:11.14 |
| | But you may have to wait a bit for an answer | 09:11.26 |
| mrev1l | well, that is not a problem. so, here is the deal | 09:12.49 |
| | my friend and i are developing an application that would provide tools to work with pdf annotations. we faced an issue, while adding an ellipse annotations. the thing is, - not every pdf viewer would see the annotation, which we add. we tried to create an ellipse annotation in a different app(foxit reader), then parse it and compare pdf_obj in order to understand, what is the problem with our implementation. | 09:19.59 |
| | buuuut, we had hard time, understanding, what is exactly stored in this type, cause the field names (of pdf_obj) are...a bit unclear | 09:21.57 |
| kens | THs isn't something I'm going to be able to help with, you'll have to wait until someone else with more knowledge comes online. | 09:22.46 |
| | My *guess* would be that you aren't generatin an Appearance stream for the annotation, in the absence of an appearance stream a PDF consumer can do anything (including nothing) that it wants to. | 09:23.31 |
| | Note that Acrobat always ignores appearance streams and generates them, Ghostscrip will generally generate them if they are missing. Other consumers differe widely in their behaviour. | 09:24.11 |
| mrev1l | so basically i'm just wondering if you guys could give us some advise and\or guidance...... yeah, sure, i will wait.... thank you | 09:24.16 |
| sebras | Robin_Watts: congrats mr. watts! | 09:46.17 |
| kens | Did I miss something ? | 09:46.36 |
| sebras | kens: birthday! | 09:46.44 |
| kens | Ah, I never know when people's birthdays are, I have enough trouble with my own | 09:47.06 |
| sebras | kens: yeah, I recognize this myself. :) | 09:47.37 |
| simon91 | tor8: hey, I thougth a bit more about the slow formatting of floating points in fitz. | 10:31.10 |
| | tor8: looks like some libc implementations indeed fail to do the rounding in printf correctly | 10:31.57 |
| | see Exact floating point printing in http://www.etalabs.net/compare_libcs.html | 10:32.37 |
| | tor8: my current plan is to build formatting code based on the printf code in the musl libc. One question: Is it portable enough to assume IEEE artihmetic in mupdf? that would simplify things. | 10:35.35 |
| | internally, the musl printf code deals with long doubles. As we only need single precision, a lot of it can be optimized for that case. | 10:38.58 |
| tor8 | yes, we can safely assume IEEE floating point math. the main "problem" with the libc implementations is the focus on double precision math | 10:39.33 |
| simon91 | Ok good :-) | 10:39.58 |
| | the code in musl I'm talking about is in the "fmt_fp" function in http://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c | 10:42.14 |
| | A lot of it can be discarded, as we only need a single output format, as specified in the PDF spec. | 10:43.15 |
| | Yeah and that code is pretty unreadable. But still the most simple implementation I found. (looked: musl, glibc, newlib, freebsd) | 10:44.36 |
| | to extract the sign, exponent and mantissa bits of the IEEE float I need to do type pruning like | 10:47.23 |
| | float x = 1.1; union {float f; uint32_t u} y.f = {x}; uint32_t = y.u; | 10:47.23 |
| | nonsense, that should be "union { float f; uint32_t u; } y = { x }" | 10:50.07 |
| | that's valid code in C99 but not C89 | 10:50.36 |
| | AFAIK it's still undefined behaviour in C++ | 10:54.04 |
| | (though works with g++) | 10:54.23 |
| | is it necessary for us to write C++ compatible C? | 10:55.13 |
| Robin_Watts | simon91: You can assume that using unions to extract stuff is fine. | 10:59.23 |
| simon91 | Robin_Watts: ok thanks. | 11:01.43 |
| | ok, I guess there is no legal problem in importing modified musl code (MIT license). I hope it won't have mutch similarity with the musl code (no comments, variable names a,b,c,d, ...x,y,z) once it's ready. | 11:05.06 |
| | tor8: are we sure, that we will never need to format double precision numbers? | 11:07.27 |
| | otherwise it would be premature to optimize for floats | 11:07.58 |
| Robin_Watts | simon91: ISTR that the implementation notes in the pdf ref specify floats. | 11:09.40 |
| | To represent real numbers, Acrobat 6 uses IEEE single-precision floating-point numbers, as described in the IEEE Standard for Binary Floating-Point Arithmetic (see the Bibliography). | 11:10.22 |
| | apparently. | 11:10.27 |
| simon91 | Ok. Does that also hold for the other document formats? | 11:12.09 |
| Robin_Watts | Not a clue for xps, but I don't think we care. | 11:12.34 |
| simon91 | We can only write pdf at the moment, can't we? | 11:12.57 |
| Robin_Watts | yeah. | 11:13.09 |
| tor8 | we have taken pains to avoid using doubles in mupdf where we can | 11:13.20 |
| | at one time, we had to rely on floating point emulation for certain platforms | 11:13.36 |
| | like the early iphones and androids without an fp unit in the arm, IIRC | 11:13.52 |
| simon91 | sounds like fun | 11:14.11 |
| tor8 | if I were to rewrite mupdf today, I'd probably just have used doubles everywhere | 11:14.30 |
| | ... also for integers | 11:15.02 |
| | but for now, we're committed to floats | 11:18.47 |
| simon91 | I made some profiling with the glibc printf, that is i simply replaced fz_ftoa with printf("%f", x). doing so pdf_write_document became about 20 times faster for files with many annotations and outline entries. (I used the glibc manual). | 11:26.18 |
| | But accourding to cachegrind and perf, the printf was still the bottleneck. | 11:26.18 |
| | The glibc printf uses really slow multi-precision arithmetic. | 11:27.11 |
| | The only proper solution is to write code, that is completely independent of the libc | 11:27.41 |
| | (at least in that particular case) | 11:28.11 |
| tor8 | simon91: yes, floating point formatting is slow. using code specialized for single precision floats should help, as would not iterating each number up to 10 times through printf/scanf | 11:29.18 |
| simon91 | time for me to go. CU | 11:53.22 |
| mrev1l | could anyone be so kind to give a hint in setting an appearance stream in terms of c++ coding? i've tried using pdf_set_annot_appearance, but after that pdf_annot->ap still returnes NULL. or i am losing something? | 12:15.29 |
| Robin_Watts | mrev1l: You might need to synthesise the appearance stream too? | 12:44.00 |
| mrev1l | Robin_Watts: yeah, i guess so | 12:45.29 |
| Robin_Watts | pdf_set_annot_appearance runs the given display list through the pdfwrite device to make a new appearance stream. Not sure why that's not showing up | 12:47.28 |
| | possibly we are just not updating annot->ap. I think the value in the actual file must be updated. | 12:48.54 |
| | Ah, right. | 12:50.11 |
| | If you look at pdf_update_text_annot_appearance for example. | 12:50.22 |
| | That calls pdf_set_annot_appearance then doe: | 12:50.32 |
| | /* Drop the cached xobject from the annotation structure to | 12:50.44 |
| | * force a redraw on next pdf_update_page call */ | 12:50.46 |
| | pdf_drop_xobject(ctx, annot->ap); | 12:50.48 |
| | annot->ap = NULL; | 12:50.49 |
| | So pdf_update_page presumably fixes it. | 12:51.02 |
| mrev1l | Robin_Watts: thank you, for your help. it helped to set annot->ap...but my initial problem remained unsolved. as i had already mentioned, the issues is, that some of pdf viewers do not see; hence, show the annotation i add with my code | 15:45.24 |
| kens | I'd suggest that you compare the annotations you produce with those from other viewers and consult the PDF reference to see what the differences are. | 15:48.53 |
| mrev1l | the thing is that in PDF reference, the only required field for circle\ellipse is SubType(FZ_ANNOT_CIRCLE) and a BBox, plus some viewers do open everything correctly. that's when i got confused | 15:52.01 |
| kens | If there is no appearance stream the viewer can do what it likes. As I siad before, Acrobat *always* ignores the AP and generatres a new one. GS honours it, but if its missing will create one. Other viewers will do other things. | 15:53.01 |
| | We can't realistically tell you what other people's viewers are doing. We can explain what MuPDF or Ghostscript are doing with your annotation, but if other viewers do different stuff, well we can't tell you why. | 15:53.44 |
| mrev1l | i understand that. thank you for your time | 15:54.16 |
| kens | To find out you need to modify a working annotaton to the point where it stops working, then you know what that viewer needs | 15:54.17 |
| rayjj | mvrhel_laptop: question for you on #artifex | 22:13.43 |
| | Forward 1 day (to 2015/11/21)>>> | |
IRC Logs