| | <<<Back 1 day (to 2017/08/15) | 20170816 |
| sebras | tor8: hm... I think having a function return a pointer to the indexed palette is still better than asking for each index. the latter just gets messy. | 11:56.05 |
| | tor8: I did rename the function on sebras/master though., | 11:56.29 |
| tor8 | sebras: yeah. just make the name a bit less ambigous and it's good to go, I reckon. | 11:56.30 |
| | sebras: all except "Add support for writing pdfs usin Lab colorspaces." LGTM | 11:58.28 |
| | though the top one could do with a bit of fz_colorspace_is_rgb instead of looking at the number of components | 11:58.47 |
| | maybe we should just add a fz_base_colorspace enum with FZ_COLORSPACE_RGB, _GRAY, _CMYK, _LAB? | 11:59.14 |
| | or fz_colorspace_type | 11:59.34 |
| | FZ_COLORSPACE_SPOT and FZ_COLORSPACE_INDEXED for the funky ones | 12:00.04 |
| | I think that would be cleaner than the mess we have now with comparing function pointers and names by strings etc | 12:00.27 |
| | we should probably run that idea through robin once he gets back (how long is he gone, two or three weeks?) | 12:01.02 |
| | switch (fz_base_colorspace(ctx, cs)) { case FZ_COLORSPACE_RGB: etc | 12:01.38 |
| sebras | tor8: two weeks I think. | 12:08.50 |
| kens | Back on the 28th ? | 12:09.07 |
| | I think he said that somewhere | 12:09.15 |
| | Yeah 11th->28th | 12:10.09 |
| sebras | tor8: I removed the lab stuff altogether, until we can ask robin. | 12:12.36 |
| | tor8: but waiting with the fix for 698168 seems a fit unnecessary..? | 12:13.04 |
| | tor8: I think it really should just be a fz_colorspace_type enum, as it would not just apply to the base colorspace in an indexed colorspace, but conceivably could apply to all colorspaces. | 12:14.22 |
| tor8 | yes, sorry, I was a bit confusing there | 12:27.43 |
| | I did mean for all colorspaces :) | 12:27.49 |
| | switch (fz_colorspace_type(ctx, fz_indexed | 12:28.06 |
| | _colorspace_base(ctx, cs)) { case ... | 12:28.14 |
| | sebras: there's a handful of commits on tor/master for review | 12:37.17 |
| | robin has given a vague head nod to the ones up to "Use font name in HTML output." but a final ack by you would be good | 12:37.41 |
| sebras | tor8: that means that sebras/master is good to go? | 12:50.59 |
| | tor8: if so I'll push and next review tor/master. | 12:51.08 |
| tor8 | sebras: yup, LGTM now. | 12:51.48 |
| sebras | tor8: excellent! | 12:54.09 |
| | tor8: hm.. that initial commit was... short. | 13:07.09 |
| tor8 | sebras: yes. better to just read the final file, pretty much everything changed. | 13:07.33 |
| sebras | tor8: gah! I messed up the top commit on origin/master, it lacks the fz_colorspace declaration. it was sitting git add:ed but forgot to git amend it. help? | 13:10.51 |
| | tor8: also, cluster would need to be reset. | 13:11.01 |
| | tor8: I noticed this when I couldn't check out the first commit on tor/master. :-/ | 13:11.35 |
| tor8 | sebras: I have no idea how to prod the cluster | 13:11.54 |
| | chrisl maybe knows? | 13:12.04 |
| sebras | tor8: sorry. :-( | 13:14.48 |
| chrisl | Sorry, what's up? | 13:15.02 |
| kens | thinks cluster wrangling is a Robin job | 13:15.20 |
| chrisl | Hmm, I'm not even getting the dashboard loading :-( | 13:15.43 |
| kens | LOL *I* cna do better than that :-D | 13:16.05 |
| tor8 | chrisl: sebras wants to back out the last commit on mupdf origin/master and make sure the cluster doesn't get stuck | 13:16.24 |
| kens | ATM my test is nearly finished | 13:16.26 |
| chrisl | tor8, sebras: okay, give me five minutes | 13:16.48 |
| | sebras: So, which commit specifically do you want dropped? | 13:17.13 |
| sebras | chrisl: 45ec7e2da | 13:19.16 |
| chrisl | sebras: okay | 13:19.27 |
| sebras | chrisl: thanks. | 13:19.45 |
| | tor8: dev->curdir = direction_from_bidi_class(ucdn_get_bidi_class(c), dev->curdir); in source/fitz/stext-device.c is before declarations. | 13:36.43 |
| | tor8: why didn't our new fancy flag catch that? | 13:37.08 |
| tor8 | sebras: because clang doesn't support it... | 13:51.59 |
| | will fix | 13:52.53 |
| sebras | ah. | 13:53.04 |
| | tor8: does the pool zero all memory? | 13:53.59 |
| | tor8: otherwise I'm briefly puzzled as to why add_char_to_line() doesn't accidentally include non-set values in the line's bbox. | 13:54.30 |
| tor8 | it does | 13:54.31 |
| sebras | tor8: ok, that explains why add_line_to_block() doesn't set the bbox. | 13:55.08 |
| | tor8: why don't I find the zeroing in fz_pool_alloc()? | 13:55.33 |
| tor8 | fz_malloc_struct does the zeroing | 13:55.45 |
| sebras | right, that always throws me. | 13:56.28 |
| | tor8: I forget that it is fz_calloc() underneath. | 13:56.41 |
| | tor8: question: does it matter that we don't set lastchar when inserting an image? | 14:01.26 |
| tor8 | sebras: no, since then the cur_block will not be a FZ_STEXT_BLOCK_TEXT block so cur_line will be null | 14:08.32 |
| | so we'll always end up in the 'new_para = 1; new_line = 1;' if block | 14:09.58 |
| sebras | and because cur_line == NULL we will never even check dev->trm | 14:12.15 |
| | add_char_to_line() doesn't appear to use rtl. | 14:13.32 |
| | a missing TODO for rtl? | 14:13.50 |
| tor8 | sebras: oh crap... looks like the ch->rtl = rtl; line has gone missing in one of the rebase reshuffles | 14:18.40 |
| sebras | tor8: also it seems you do not need to include stdio.h any more since you killed all debug printing..? | 14:26.46 |
| | tor8: in fz_print_stext_block_as_xhtml() you print \n when it is not the first line of a block, but used to print <br>\n. | 14:32.56 |
| | tor8: why? | 14:32.59 |
| | tor8: i.e. why the change? | 14:33.07 |
| | also the final </p> in a block has a trailing newline instead of an initial one. | 14:34.01 |
| | tor8: is this so that you will get <p>this is text\nthis is more text\nthis is the last line</p> perhaps? | 14:34.51 |
| chrisl | sebras: I think I have bludgeoned the cluster into shape - we'll see when the current queue clears | 14:35.46 |
| china-bing | hello~~ | 14:45.57 |
| sebras | china-bing: hello, please ask your question. :) | 14:46.32 |
| china-bing | mujs have some ext-lib? like node.js | 14:49.06 |
| | @sebras no file,no serial,no network lib,to many thing want to code,so tried~~ | 14:55.25 |
| tor8 | sebras: yes. and with whitespace:pre-wrap we get HTML to break on newlines (and it's easy to turn off with another CSS rule override if you want it) | 14:57.37 |
| | which you can't do if we hardcode <br/> tags | 14:57.46 |
| | china-bing: no. the mujs shell has a few functions to read and write files. the library is designed to be minimal, ECMA spec functions *only*. | 14:58.35 |
| | any extras you need to provide yourself. the same way as Lua does it. | 14:58.46 |
| china-bing | i already code a lot of lua interface,now want to change js ... | 15:06.14 |
| | list | 15:09.54 |
| | @sebras mujs can support function(){ do something} or setIntervel(function(){do something}) grammar? | 15:19.45 |
| sebras | tor8: sorry for dropping out, judy called. | 15:38.31 |
| | china-bing: I'm not an expert on mujs, you need to talk to tor8. | 15:39.03 |
| | china-bing: mujs supports writing functions, anonymous functions I don't know about. | 15:39.55 |
| | china-bing: I don't think setInterval() is in the javascript specification. | 15:49.55 |
| | china-bing: so mujs doesn't support it. | 15:51.04 |
| | tor8: ok! I have now reviewed the first patch on tor/master fully. | 15:55.47 |
| | tor8: and I refetched tor/master and noticed that you fixed my comment about the declaration, but not the one about rtl. | 15:57.15 |
| | tor8: maybe you have it locally. | 15:57.21 |
| | tor8: for (b=0, spaces? | 16:01.07 |
| | tor8: this is in c17a769 btw. | 16:01.19 |
| | same with l=0 | 16:01.37 |
| | why only here? | 16:01.39 |
| | tor8: oh, I meant in 4986ff8f5 | 16:03.33 |
| | tor8: and now I found e0e03f738 fixing the rtl too. | 16:03.44 |
| | tor8: why is a1097c1d not merged into 25e27b780? | 16:05.01 |
| | tor8: I generally like taking a stepwise approach, but I know you like doing it in bulk, and mat_sig_eq() lives just for three commits or so. strange. :) | 16:05.41 |
| | tor8: and in a1097c1d, why compare < 0.999f ? why not 1.0f? | 16:06.44 |
| | tor8: in 8111fb6bc you state that PWG has a colorspace option but while you don't parse it in fz_parse_pwg_options(), you do it directly in fz_new_pwg_writer() | 16:16.36 |
| | tor8: in e58619791 you do the parsing of the options in fz_parse_pcl_options(). that seem more correct. | 16:17.22 |
| | tor8: there might be a subtle difference I don't yet get. | 16:19.49 |
| | tor8: reviewed until and including 56edfda1e, I see nothing strange apart from what I have already written. | 16:22.51 |
| tor8 | sebras: re: spaces, oops. | 16:26.23 |
| | sebras: because possible rounding errors during matrix math may make the vectors not align perfectly | 16:27.32 |
| | for the 0.999f | 16:27.37 |
| | sebras: colorspace=mono is parsed by the draw device (as a synonym for 'gray') | 16:28.17 |
| | because parse_pwg_options fills in the pwg_option struct (which doesn't have a 'mono' field) | 16:28.54 |
| | and I didn't want to mess with those (since I don't completely understand what should be in there without asking robin) | 16:29.36 |
| sebras | tor8: back. | 16:35.55 |
| | tor8: so why does it help to compare < 0.999f instead of < 1.0f? | 16:37.10 |
| | tor8: re: options: I see, but that seems a bit awkward. it seem to me that the options struct is just a place holder for all options. | 16:38.42 |
| | tor8: I'd like to see that in the options struct instead of in the writer itself. but yeah, confirm it with robin. | 16:39.10 |
| tor8 | sebras: because 0.999f is equivalent to 1 degrees, which is close enough | 16:52.33 |
| sebras | tor8: why is the half-open interval [0.9990000000000000001f - 1.0f[ not interesting? I can see why the result might be 0.999f and so why you shouldn't e.g. compare to == 1.0f. | 16:54.46 |
| | tor8: but comparing to <1.0f ought to be safe, no? | 16:55.57 |
| tor8 | if the matrices are almost the same, < 1.0 might fail when we don't want them to | 18:47.50 |
| | we want to treat matrices that are very close but rounding errors off as equal | 18:48.50 |
| | which < 1.0 doesn't | 18:49.01 |
| | anyway, gotta go. talk more tomorrow. | 18:50.49 |
| sebras | tor8 (for the logs): I see. now I get it. and 0.999f is just an arbitrarily close number 0.9999f might also do. | 20:36.31 |
| | Forward 1 day (to 2017/08/17)>>> | |
Log of #mupdf at irc.freenode.net.