| | <<<Back 1 day (to 2016/02/23) | 20160224 |
| ediee | Robin : Hi | 05:33.27 |
| | Hi | 05:34.05 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 05:34.05 |
| ediee | can anyone will help me out for mupdf's reflow mode | 05:40.10 |
| | ? | 05:40.11 |
| | Hello everyone | 05:58.38 |
| | can i get any help for mupdf's reflow mode | 05:58.50 |
| | ? | 05:58.51 |
| | can anyone here? | 06:30.57 |
| | HI everyone | 09:34.12 |
| | Can i get help for mupdf's reflow mode | 09:34.27 |
| | ? | 09:34.31 |
| kens | ediee as explained you are not a customer, so any support is entirely at our discretion, we do have other things to do. Right now you are too early (as you were 4 hours ago) for anyone much to be around. Please don't keep pinging pepole, this channel is logged an the logs *are* read by the engineers. If you stick around (or read the logs yourself) someone will answer. | 09:35.58 |
| | I thnk you will need to make an example file available before anyone can help you any further in any event, as I suggested yesterday. | 09:36.20 |
| ediee | im ready to do that but nobody is replying then how can i ask questions?? | 09:37.00 |
| kens | Wiat. | 09:37.06 |
| | Wait. | 09:37.10 |
| ediee | i was in conversation with robin yesterday | 09:37.19 |
| kens | You are asking quesotns when nobody is around. SO don't. Ask once and wait | 09:37.24 |
| | As I said, the channel is logged (hence why I see you asking the same questions 4 hours ago), and the engineers do read the logs. | 09:37.50 |
| | So when someone turns up and is prepared to discuss ths with you, they will answer | 09:38.09 |
| ediee | I understand.. as u said you have other things to do likewise I too have other things to do.. I cant wait upto 4 hrs right? | 09:38.37 |
| kens | You can wait longer than that. THe poeple you need to speak to are in Europe (I odn't know where you are based) so you could wait a long time | 09:39.16 |
| ediee | ok I have to wait now also | 09:39.35 |
| | or will u reply for the question? | 09:39.43 |
| kens | I don't work on MuPDF so I cannot answer your question | 09:39.58 |
| ediee | very well then | 09:40.20 |
| | thanks for ur commets | 09:40.23 |
| xd1le | ediee: you don't have to wait continuously, you can ask your question and do other things, keep the irc client connected and check back later | 09:53.37 |
| | :) | 09:54.25 |
| | there are public logs at http://ghostscript.com/irclogs/, so you can even ask your question and disconnect, and then read the logs later to see if anyone answered | 09:55.58 |
| ediee | xd1le : ok thank you | 09:59.27 |
| Robin_Watts | ediee: Morning | 10:28.10 |
| ediee | Robin : Morning | 10:31.44 |
| | Robin : I tried ur yesterdays solution.. But the issue with the layout | 10:32.41 |
| | how can I solve it | 10:32.47 |
| | Can i share an example with u | 10:32.52 |
| | ? | 10:32.53 |
| Robin_Watts | ediee: You can. | 10:33.10 |
| | Go to bugs.ghostscript.com, register, and then open a bug. Attach the smallest example file you can that shows the problem. | 10:33.32 |
| ediee | Robin : i assigned the bug | 10:39.02 |
| | Bug 696614 | 10:39.03 |
| Robin_Watts | ediee: There are no images in that file. | 10:41.50 |
| | The diagrams are line art, not images. | 10:42.02 |
| | We can't carry line art into the HTML. | 10:42.15 |
| ediee | u mean to say that the html is correct? | 10:43.13 |
| | as u can see the pdf and the html | 10:43.25 |
| | its totally different | 10:43.28 |
| Robin_Watts | ediee: I cannot be any clearer. | 10:43.48 |
| | There are no Images in the PDF. Therefore there are no images in the HTML. | 10:44.10 |
| | The diagrams in the PDF are NOT images. | 10:44.23 |
| ediee | ok agreed | 10:44.38 |
| | then how to carry those diagrams into html | 10:44.46 |
| | ? | 10:44.47 |
| Robin_Watts | We can't. | 10:44.53 |
| ediee | then I think those diagrams can be converted into images then we can add those diagrams into images in html | 10:45.31 |
| Robin_Watts | ediee: Sure. Go for it. I'll be interested to see what you come up with. | 10:46.27 |
| ediee | can i get those diagrams as images in mupdf? | 10:46.48 |
| Robin_Watts | edie:: MuPDF can be told to render any part of a page. | 10:49.02 |
| | but how do you know what part of the page to render ? | 10:49.12 |
| ediee | Robin : thats only my question since from yesterday | 10:49.36 |
| | the diagrams / images are not extracted in reflow mode | 10:50.15 |
| Robin_Watts | ediee: No. | 10:52.47 |
| | Yesterday you insisted that you had a file that had IMAGES in it, and that they weren't being extracted. | 10:53.08 |
| | We now see that the files have no images. | 10:53.20 |
| | NOW you are asking if there is a way to extract the diagrams as images. | 10:53.36 |
| ediee | yess | 10:53.44 |
| Robin_Watts | and I am saying, "No, MuPDF does not support that." | 10:53.49 |
| | You then asked if MuPDF could draw those diagrams to images, and I said "Yes, MuPDF can draw any given area of the page to an image, but you need to somehow figure out what area of the page to draw" | 10:54.32 |
| | and that is NOT an easy thing to do. | 10:54.43 |
| | There is no marker in the PDF file to say "this bit of the page contains a diagram". | 10:55.00 |
| ediee | then how can we achieve the reflow mode | 10:55.38 |
| | in all conditions | 10:55.42 |
| | like diagrams, images, formulaes, scientific notations and many more | 10:56.02 |
| Robin_Watts | ediee: With current MuPDF, you cannot. | 10:56.05 |
| ediee | can we expect this in future with mupdf? | 10:57.02 |
| Robin_Watts | ediee: It's not on the immediate list of things to look at, no. | 10:58.41 |
| ediee | ok | 10:59.34 |
| chrisl | Note that there will *always* be aspects of PDF that cannot be represented in HTML | 10:59.57 |
| ediee | Robin and Chrisl : Can we determine somehow or anyhow that the page contains the diagrams, images, notations etc.. | 11:00.54 |
| | ? | 11:00.55 |
| Robin_Watts | ediee: It would be possible to detect that a page has lineart on that won't translate, yes. | 11:01.45 |
| ediee | can u tell me how can we get that? | 11:02.31 |
| Robin_Watts | ediee: You'd need to modify the internals of MuPDF. | 11:11.10 |
| | Specifically, the stext device. | 11:11.21 |
| | It consists of various functions that get called for each different thing on the page (images, text, paths etc). | 11:11.44 |
| | You'd need to add some code that sets a flag when (say) a path was encountered. | 11:12.02 |
| tor8 | Robin_Watts: cluster looks unhealthy on the dashboard | 11:12.03 |
| Robin_Watts | tor8: I suspect miles' office just fell off the net :) | 11:12.51 |
| | It'll sort itself out in a few minutes. | 11:13.04 |
| tor8 | Robin_Watts: I was seeing some odd time increases on my last run :/ | 11:13.27 |
| | Robin_Watts: if you got a mo to look over tor/master I'd be grateful | 11:13.37 |
| | but something is causing it to run slower than before, which I did not expect | 11:13.52 |
| Robin_Watts | ediee: Are you a competent C programmer? | 11:13.53 |
| | tor8: fetching now. | 11:14.09 |
| ediee | Robin : No | 11:14.56 |
| Robin_Watts | tor8: I see 10 commits on robin/master. Have you had a clean run out of any of them ? | 11:15.15 |
| | ediee: Then you're in trouble :( | 11:15.23 |
| tor8 | Robin_Watts: that's what I was trying to do when the cluster fell over | 11:16.17 |
| Robin_Watts | tor8: I mean, is it just the last commit that's broken, or might it be any of them? | 11:16.43 |
| tor8 | I suspect the first of them | 11:17.01 |
| | the clip function scissor one | 11:17.12 |
| Robin_Watts | I can't see anything wrong with that offhand. | 11:21.38 |
| | Let's wait for the cluster to recover. | 11:21.48 |
| tor8 | Robin_Watts: the wmode one, I don't know if you saw my ramblings about XPS having a BidiLevel annotation to text objects | 11:22.24 |
| Robin_Watts | I did. | 11:22.33 |
| | Does that mean that XPS is expected to do shaping etc? | 11:22.41 |
| | XPS gives unicode, rather than glyphs, right? | 11:23.06 |
| tor8 | XPS is expected to have had shaping done already, but it stores bidilevel and unicode "cluster map" information to recover the high level text | 11:23.10 |
| | XPS gives both | 11:23.17 |
| Robin_Watts | Ah, gotcha. | 11:23.22 |
| tor8 | so we could revert the wmode commit and add bidilevel as well as wmode to fz_text | 11:24.16 |
| Robin_Watts | oh, wait, bidilevel. | 11:29.12 |
| | That's like the number of nestings within the bidi classification stuff? | 11:29.45 |
| tor8 | yeah, looks that way from the XPS spe | 11:29.57 |
| | c | 11:29.58 |
| Robin_Watts | I don't extract that from the bidi code at the moment, but could do if required. | 11:30.12 |
| | I sincerely hope we never need it. | 11:30.18 |
| tor8 | I'd say we postpone that idea for a while | 11:30.37 |
| | the bidilevel in xps is mostly there to advance the pen position going left or right depending on whether it's odd or even | 11:32.03 |
| Robin_Watts | oh, well, we can extract the bottom bit of that as left or right then ? | 11:54.16 |
| tor8 | Robin_Watts: results came in for the clip commit ... 16 minutes slower than trunk | 11:54.25 |
| Robin_Watts | ok, cluster looks back. | 11:54.27 |
| tor8 | Robin_Watts: yes | 11:54.29 |
| Robin_Watts | tor8: So, IIRC from looking at it, we are doing bounding operations in 1 more case than before... | 11:55.12 |
| | but no diffs? | 11:55.25 |
| tor8 | zero diffs | 11:55.41 |
| | the only real changes are coping with null in clip_image_mask and adding the scissor to clipped text | 11:57.17 |
| Robin_Watts | tor8: Yeah. | 11:57.32 |
| tor8 | I have a hard time seeing how clipped text is common enough to add 17 minutes of runtime to the cluster... | 11:57.36 |
| Robin_Watts | Indeed. | 11:57.50 |
| | Can we split those bits and test separately? | 11:58.01 |
| tor8 | yeah, I'll do that | 11:58.11 |
| Robin_Watts | actually, 17 minutes of runtime *may*be down to the fact that we only have a limited set of cluster nodes. | 11:58.30 |
| | If we've lost more "high power" cluster nodes, then that might explain it. | 11:58.48 |
| | kens: You here? | 11:59.47 |
| tor8 | well, makes sense to split the commit anyway so I might as well try it. | 12:01.06 |
| Robin_Watts | chrisl: Do you know anything about the gstype1.c code ? | 12:07.05 |
| tor8 | Robin_Watts: yeah, now I'm getting a run time of 25 minutes slower | 12:11.02 |
| | I blame the cluster... | 12:11.05 |
| Robin_Watts | tor8: So with the new code it's 8 minutes faster? :) | 12:11.27 |
| malc_ | wow | 12:12.37 |
| tor8 | Robin_Watts: with the text clip masks it's 8 minutes faster ... if anything can be trusted ;) | 12:13.11 |
| | Robin_Watts: did you look at the other commits as well? it would be nice to get sebras stuff to golden before I start digging into the pdf-create branch. | 12:15.23 |
| Robin_Watts | tor8: Let me look again. | 12:15.37 |
| | I thought we were avoiding the wmode -> font move ? | 12:16.10 |
| tor8 | I can't make up my mind. This makes sense for PDF but is slightly at odds with XPS. | 12:17.13 |
| Robin_Watts | I've looked over sebras code several times and I'm happy. | 12:17.21 |
| | I don't understand the last 2 commits yet. | 12:17.32 |
| tor8 | they are the final bits of polish to get whitespace handling done correctly | 12:17.48 |
| chrisl | Robin_Watts: What about the gstype1.c code? | 12:18.04 |
| tor8 | there were a few corner cases we'd get wrong, and we didn't handle all white-space css variants correctly | 12:18.19 |
| Robin_Watts | chrisl: Can I come back to you in 5 mins please? | 12:18.38 |
| | (sorry) | 12:18.42 |
| chrisl | I'm going to get some lunch, so after that | 12:18.52 |
| Robin_Watts | (or later, at your convenience) | 12:18.56 |
| | Sure, thanks. | 12:18.59 |
| | tor8: Ok, the first of those commits looks plausible. | 12:21.21 |
| | and I'm going to nod sagely at the last one and pretend I understand it. | 12:23.41 |
| | So, all of those look fine, except for the wmode one, which I think we should leave out for now. | 12:23.56 |
| tor8 | Robin_Watts: okay. I'll take that out for now then. | 12:25.07 |
| | Robin_Watts: reworked wmode commit on tor/master | 12:43.22 |
| Robin_Watts | lgtm | 12:44.45 |
| chrisl | Hmm, no bugzilla :-( | 12:44.59 |
| tor8 | Robin_Watts: thanks. | 12:45.07 |
| chrisl | Robin_Watts: back now, so whenever...... | 12:52.17 |
| Robin_Watts | chrisl: cool. | 12:52.29 |
| | I updated the code a while ago to catch a load of places where return codes were being ignored. | 12:52.52 |
| | One of the places I changed was pdfwrite. | 12:53.06 |
| | Now that turns out to have caused a problem in pdfwrite close down, resulting in a lack of content in the files. | 12:53.35 |
| | The exact problem is that a call to pdf_write_embedded_font gives a rangecheck error. | 12:54.48 |
| | That in turn is failing because psf_write_type1_font is failing. | 12:55.15 |
| | which is failing because of psf_get_type1_glyphs | 12:56.16 |
| | which is failing because of psf_get_outline_glyphs | 12:56.25 |
| | which is failing because of psf_check_outline_glyphs | 12:56.40 |
| | which is failing because of pfont->procs.glyph_info | 12:57.17 |
| | which is failing because of gs_type1_interpret (or type1_next, can't remember) | 12:58.17 |
| | and that is failing because of gs_type1_check_float | 12:58.33 |
| | specifically the if (c != cx_escape) clause there. | 12:58.54 |
| chrisl | Well, clearly, psf_check_outline_glyphs() shouldn't return immediately on an error | 12:59.00 |
| | Hmm, and it doesn't but only special cases certain errors...... | 13:02.06 |
| | Robin_Watts: The thing is, if it's one (potentially unused) glyph throwing the error, that probably shouldn't a) inhibit embedding the font, nor b) stop the output being written | 13:04.01 |
| Robin_Watts | chrisl: Absolutely. | 13:04.25 |
| kens | Hmm I did say at the time that I wasn't convinced all those uncaught errors were safe to catch :-) | 13:04.40 |
| Robin_Watts | kens: yes, you did. | 13:04.53 |
| kens | I'd look at it myself but I'm still thrashing around in the dark with ths performance nightmare | 13:05.04 |
| Robin_Watts | my unspoken feeling at the time was that we should catch them and if they are a problem EXPLICITLY drop them. | 13:05.23 |
| kens | Yes, there are places where I already do that | 13:05.39 |
| | Usually along with a comment | 13:05.53 |
| | But of course that only holds for places where I've changed the code myself | 13:06.15 |
| Robin_Watts | My current fix here is to swallow rangecheck errors returned from pdf_check_outline_glyphs. | 13:06.31 |
| | That (I believe) solves the bug, but it may not be optimal | 13:06.51 |
| kens | I'd say do that, and open a bug report for me to look at in the future | 13:07.03 |
| Robin_Watts | kens: I'll do that, and then repoint the existing bug to you, with comments about what I know. | 13:07.42 |
| | Thanks. | 13:07.45 |
| kens | NP | 13:07.48 |
| | I'd forgotten there was an existing bug | 13:08.10 |
| chrisl | Robin_Watts: I'd have thought catching and ignoring the error *in* psf_check_outline_glyphs() so it continues to enumerate all the glyphs it can (and possibly doesn't increment good_glyphs for ones that error) | 13:09.14 |
| kens | I'm reasonably sure psf_outline_glyphs is only used by pdfwrite, so yes, that's why I'd like to look at it :-) | 13:09.52 |
| chrisl | It's in the pdfwrite code, so..... | 13:10.22 |
| kens | Well the pdf_ prefix means its in the pdfwrite/ps2write family, its lower level than pdfwite itself | 13:10.47 |
| | psf_ I mean | 13:10.53 |
| chrisl | Lordy, we have gs_imager_state_initial() *and* gs_imager_state_initialize()...... | 13:13.47 |
| Robin_Watts | chrisl: I could make psf_check_outline_glyphs continue on to the end, but I feel that we ought to *somehow* return the error. | 13:14.04 |
| kens | And some _aux ones and some _impl ones to go with them ? :-D | 13:14.08 |
| | Robin_Watts : it depends on why we are callign the code, I'd need to look into it | 13:14.32 |
| Robin_Watts | (i.e. swallowing the error seems wrong, but deferring the error seems reasonable). | 13:14.47 |
| | kens: indeed. | 13:14.55 |
| chrisl | Robin_Watts: the worry there would be that we'd be skipping potentially valid glyphs | 13:15.22 |
| Robin_Watts | chrisl: What I am suggesting is that we should try every glyph. | 13:15.52 |
| | but at the end we return the error if any one of them gave an error. | 13:16.04 |
| | hence we operate on every glyph, but still never drop any errors. | 13:17.01 |
| chrisl | it doesn't look to me as though that's how the code was intended to work | 13:17.53 |
| Robin_Watts | actually, it looks to me like maybe I should be ignoring the rangecheck error specifically in psf_check_outline_glyphs | 13:19.32 |
| | That already ignores gs_error_invalidfont errors for individual glyphs. | 13:20.05 |
| | but continues on through otherwise. | 13:20.14 |
| chrisl | Wish I'd thought of that...... | 13:20.34 |
| Robin_Watts | chrisl: yeah, yeah, just catching up, sorry :) | 13:20.48 |
| | Ok, I'll swap to chrisl's way of working. | 13:21.18 |
| chrisl | I'm assuming that's partly (at least) what the "good_glyphs" variable is for | 13:21.25 |
| Robin_Watts | I'll still point the bug at ken so he can double check it all at his convenience. | 13:21.45 |
| kens | OK | 13:22.32 |
| Robin_Watts | I also spotted this: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=4dac193243a94bd0baf32bb0e621562d38ce6827 | 13:22.45 |
| kens | From the conversdation, and not having looked at the code, it sounds like you should ignore all errors for glyphs, but I can't be sure | 13:23.07 |
| | So you stopped checkign for errors when releasing objects ? | 13:23.54 |
| Robin_Watts | kens: No. | 13:24.05 |
| | In those routines, we have: | 13:24.12 |
| | { int j, code = 0; | 13:25.10 |
| | for (j =0; j < n && code >= 0; j++) | 13:25.11 |
| | { | 13:25.13 |
| | some code that never alters the code variable. | 13:25.14 |
| | } | 13:25.16 |
| | } | 13:25.17 |
| kens | Hmm, I guess its copy/paste code from the first one I wrote | 13:25.33 |
| | I probably meant to go back and check code | 13:25.46 |
| Robin_Watts | kens: yeah. It's no biggy, but it had me hunting for what the magic macro that fiddled with code behind the scenes was :) | 13:26.14 |
| kens | Ah well, if its my code it doesn't (as a general rule) use macros | 13:26.34 |
| | Of coruse, its not entrely my code...... | 13:26.46 |
| Robin_Watts | I do not dislike macros as much as most people, but I loathe macros that hide variables. | 13:27.43 |
| kens | I'm fine with macros provided they are simple, clear and obviously a macro so I don't waste time trying to debug them. | 13:28.18 |
| Robin_Watts | kens: I can put that in, or I can leave it - your call. | 13:29.04 |
| kens | The code thing ? I don't mind either way | 13:29.24 |
| Robin_Watts | I'll put it in then, ta. | 13:29.36 |
| kens | OK | 13:29.40 |
| marcosw | Robin_Watts: thx for the quick fix for <http://bugs.ghostscript.com/show_bug.cgi?id=696609>. Unfortunately it only fixed the 24 bit depth case, so I've reopened the bug. | 14:19.35 |
| Robin_Watts | marcosw: Thanks. | 14:19.50 |
| | marcosw: For bug 696603, could you tell me how to actually build with address sanitizer please? :) | 14:20.19 |
| marcosw | Sure, it's not pretty but I will send out an email. | 14:20.42 |
| kens | I may need to know that as well | 14:20.49 |
| marcosw | I'll send it to tech@ | 14:21.07 |
| Robin_Watts | make gpcl6 XCFLAGS="-fsanitize=address -fno-omit-frame-pointer" fails multiple times during the build as all our tools leak like sieves. | 14:21.13 |
| | if I keep rerunning it gets further, but the final link persistently fails. | 14:21.42 |
| marcosw | yes, it involves editing the Makefile (and then editing the generated ldt.tr fiels). | 14:21.50 |
| | like I said, it's messy | 14:21.56 |
| Robin_Watts | grabs lunch. Will look at mail afterwards - thanks. | 14:21.58 |
| HenryStiles | marcosw: just build genconf and the romfs stuff separately then build with XCFLAGS and XLDFLAGS set to -fsanitize .... that's all. | 15:00.19 |
| | marcosw: reportedly chrisl has a fix a fix for the whole thing so we can just have a target once the release is done. | 15:01.08 |
| tor8 | mvrhel_laptop: morning. | 15:07.38 |
| HenryStiles | kens: obviously no priority, but we should get that simple indexed image right in pdfwrite, http://bugs.ghostscript.com/show_bug.cgi?id=696314 | 15:08.54 |
| kens | It will have to join the list | 15:09.09 |
| mvrhel_laptop | Hi tor8 | 15:26.50 |
| | brb need to grab some breakfast | 15:27.49 |
| tor8 | mvrhel_laptop: I'm going through your branch. I've got a list of questions and comments, and I figured I could get started on some of them :) | 15:28.25 |
| | so whenever you have time | 15:28.42 |
| mvrhel_laptop | tor8: ok now is fine | 15:31.14 |
| tor8 | apart from some name changes, which I easily do myself, most of it looks pretty good | 15:32.46 |
| | however, the pdf_res struct looks a bit pointless to me -- is there a reason we can't just use a pdf_obj which is an indirect reference? | 15:33.37 |
| mvrhel_laptop | tor8: good question. I originally had it returning a indirect ref. But there was a problem. Give me a sec. to remember what it was | 15:34.33 |
| tor8 | (btw, there was a lot of trailing whitespace throughout ... have you configured your git to remove it?) | 15:36.26 |
| | git config apply.whitespace fix | 15:36.56 |
| | I've wringed the branch through a git filter-branch to strip that; result is on tor/pdf_create | 15:37.23 |
| Robin_Watts | chrisl: On unix, I've just done ./autogen.sh && make clean && make gpcl6 and it's whinging that it doesn't know to make mag16.dev | 15:38.47 |
| mvrhel_laptop | tor8: So about pdf_res. The issue was that in pdf_write, we are creating the indirect referencing in the page resources using F0 F1 etc. for fonts or Im0 Im1 Im2 for images as they are added. # in F# and Im# needs to be associated with the pdf_obj so that we know how we are referencing the object and so that we can check if the page resources are already referencing it. Maybe I am... | 15:42.00 |
| | ...missing something with how to do that with a pdf_obj | 15:42.01 |
| | tor8: let me check my white space settings | 15:42.10 |
| tor8 | mvrhel_laptop: oh, so the num in pdf_res is the # in the /Im# of a specific resource dictionary? | 15:43.52 |
| | that seems fragile | 15:43.55 |
| | different pages could easily use the same resource under a different name | 15:44.05 |
| mvrhel_laptop | tor8: Yes and they do | 15:44.16 |
| | This only persists for the life of the page | 15:44.31 |
| | so page 1 can call image object Im0 and page 2 could ref it as Im2 | 15:45.10 |
| | or what ever | 15:45.13 |
| | it depends upon the order that the images are encountered | 15:45.23 |
| | no that is not true | 15:45.29 |
| tor8 | well, the pdf_res is stored in the resource tables | 15:45.42 |
| mvrhel_laptop | yes. so it is not the life of the page | 15:45.53 |
| tor8 | I'd just make pdfwrite use /F# where # is the actual object number of the resource :) | 15:46.00 |
| mvrhel_laptop | tor8: ah good point | 15:46.24 |
| | tor8: ok I will fix that | 15:46.44 |
| | I was making things more complicated than they had to be | 15:46.58 |
| tor8 | mvrhel_laptop: I did some cleanups on the resource thing (removed some of the void* casting) | 15:47.04 |
| | you can find the commits on tor/pdf_create if you want to give it a quick review before carrying on from there? | 15:47.18 |
| mvrhel_laptop | ok. that would work | 15:47.30 |
| tor8 | next thing; the font resource creation takes a fz_buffer. I would have expected it to take a fz_font. | 15:48.10 |
| | I see you take the buffer, create a new font and create a resource from that, then discard the fz_font. | 15:48.27 |
| | I would like to see it take a fz_font directly, extract the data from there (it's stowed away somewhere in the fz_font struct) | 15:48.46 |
| mvrhel_laptop | yes it is | 15:48.51 |
| | ok. that is an easy fix | 15:49.04 |
| tor8 | pdf_fontdesc_init could be turned into a pdf_new_fontdesc_from_font (and from_simple_font) and you wouldn't have to do the freetype locking dance every time you call it | 15:49.47 |
| | the first_width, last_width entries don't really belong in fz_font | 15:50.02 |
| | and if we take a fz_font in, recreating the font_widths table is going to be a no-no | 15:50.18 |
| | you could create the widths array directly in ft_width_for_simple_table, and not go via the fz_font width_table | 15:50.58 |
| | getting StemV by rendering looks like overkill. I've done some investigation and it seems that InDesign just hardcodes the StemV value to 80 :) | 15:52.06 |
| | the italic_angle and cap_height can be extracted from the freetype headers; if you get the font format specific tables out the fields are in | 15:52.40 |
| | PS_FontInfoRec and TT_Postscript and TT_OS2 | 15:52.49 |
| | personally, I'd just nuke the stemv field and hard code it to 80 when writing the font descriptor | 15:53.14 |
| mvrhel_laptop | tor8: ok | 15:53.20 |
| tor8 | in fz_new_font_from_memory we already extract some info from the TT_OS2 table | 15:54.31 |
| | you may need to create a wrapping fz_buffer for fz_new_font_from_memory to be able to get ft_buffer out for some fonts | 15:56.46 |
| | hm, that reminds me; should add a fz_new_buffer_from_shared_data that doesn't free the underlying buffer | 15:57.46 |
| mvrhel_laptop | tor8: ok trying to keep up. so on the width table | 15:59.25 |
| | right now it is filled in ft_width_for_simple_table | 16:01.11 |
| | oh but you are saying to do the allocation there too | 16:01.24 |
| tor8 | well, it's going to be a very simple 256-entry array at most | 16:01.53 |
| mvrhel_laptop | yes | 16:01.58 |
| tor8 | I figure you can create the whole pdf array, as well as first and last char entries in one go there | 16:02.15 |
| mvrhel_laptop | right. do you want first_width and last_width to be in fontdesc? | 16:02.52 |
| tor8 | I don't think we need them to be anywhere at all | 16:04.23 |
| mvrhel_laptop | The spec requires them I thought | 16:04.36 |
| tor8 | other than in local variables | 16:04.38 |
| | they need to be set when creating the font descriptor PDF object | 16:04.49 |
| | but we shouldn't need to hold on to them in our pdf_fontdesc struct | 16:05.03 |
| mvrhel_laptop | fair enought | 16:05.46 |
| tor8 | if you want I can take a bash at fixing this stuff. | 16:07.04 |
| mvrhel_laptop | I would have figured that if you had a value that was required to be written out you would want that value stored but I suppose we can recompute it | 16:07.18 |
| | tor8: if we are bumping against getting this in before the release, it may be fastest for you to do it | 16:08.05 |
| tor8 | I just don't want to step on any toes if we're both going to be fixing stuff in this code | 16:08.36 |
| mvrhel_laptop | right. I am really fine either way | 16:08.47 |
| tor8 | then I shall take a stab at fixing the font stuff today | 16:09.00 |
| mvrhel_laptop | tor8: ok sounds good | 16:09.12 |
| tor8 | I'll also see if I can poke around the pdf_res stuff I mentioned | 16:09.57 |
| | I have however managed to make mutool create crash rather spectacularly | 16:10.32 |
| mvrhel_laptop | tor8: really | 16:10.43 |
| Robin_Watts | chrisl: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=6755eb1f98105693ff02d168243807f421ef2275 ? | 16:10.47 |
| tor8 | the cleanup segfaults if there are syntax errors in the content.txt file | 16:10.49 |
| | I made a simple file with two lines "/Pages 1" and "/Page 1 500 500" and that provoked the segfault | 16:11.22 |
| mvrhel_laptop | tor8: ok. leave that for me | 16:11.38 |
| | tor8: if there is anything else left to do let me know | 16:11.53 |
| tor8 | I wouldn't mind two more command line flags to mutool create: -a and -d | 16:12.24 |
| | -a to print ascii hex encoded binary streams | 16:12.31 |
| | and -d to print in non-tight syntax | 16:12.37 |
| | (and eventually -d would toggle the compression/decompression of buffers) | 16:13.01 |
| | oh, and you do a lot of sprintf() followed by fz_write_buffer | 16:13.39 |
| | we have fz_buffer_printf :) | 16:13.43 |
| mvrhel_laptop | ah. good to know | 16:13.56 |
| HenryStiles | Robin_Watts: I build gpcl6 regularly and haven't had that problem. | 16:14.38 |
| Robin_Watts | HenryStiles: the mag16.dev thing was my fault. | 16:14.56 |
| HenryStiles | okay | 16:15.07 |
| Robin_Watts | I have a fairly small makefile change that enables easier address sanitizer builds though. | 16:15.44 |
| | Latest version: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=d5e0b0c703bd197712de0a66160f5207ed643f5d | 16:16.17 |
| HenryStiles | Be interesting to see what we get with the allocators rigged to go to malloc each time. | 16:18.21 |
| | Robin_Watts: thanks I'll grab that. | 16:19.21 |
| Robin_Watts | make pcl6sanitize (and do that repeatedly until it builds) | 16:19.50 |
| | make gpcl6sanitize (and do that repeatedly until it builds) | 16:19.55 |
| | I think bug 696603 is bogus. | 16:23.02 |
| | mem_mono_copy_mono does cunning load/shift tricks to cope with copying unaligned data. | 16:23.39 |
| | as such it can read beyond the end of data, but won't actually use the data it reads. | 16:24.06 |
| HenryStiles | Robin_Watts: well yes with repeating I can just do: make gpcl6debug XCFLAGS=-fsanitize=address XLDFLAGS=-fsanitize=address | 16:24.07 |
| Robin_Watts | HenryStiles: Yes. | 16:24.30 |
| | All my change is is to add some new targets to basically do that. | 16:24.59 |
| | Except that with my change you can still specify XCFLAGS etc. | 16:25.12 |
| | It's not rocket science. | 16:25.28 |
| mvrhel_laptop | tor8: so I fixed my git to remove the trailing white space. for those of you who use VS, found this https://visualstudiogallery.msdn.microsoft.com/a204e29b-1778-4dae-affd-209bea658a59. Also found that CTRL+k CTRL+d removes trailing white space | 16:26.20 |
| Robin_Watts | There *may* be a fix we can do to avoid the repeating problem, but it's more invasive. | 16:26.21 |
| | Ctrl-K/Ctrl-D reformats doesn't it? | 16:26.44 |
| | Nice find on that tool though I will add that now. | 16:27.05 |
| HenryStiles | Robin_Watts: chrisl said he has a fix, he just doesn't want to muck with genconf now understandably | 16:27.06 |
| mvrhel_laptop | Robin_Watts: hmm maybe | 16:27.08 |
| | anyway, the tool is nice to quickly see them | 16:27.41 |
| Robin_Watts | HenryStiles: Ah, I was thinking of putting '-' before each tool invocation. | 16:28.01 |
| mvrhel_laptop | bbiab | 16:28.15 |
| Robin_Watts | possibly conditionally, if Make will support that. | 16:28.18 |
| | $(SAN_EXE)mkromfs .... etc | 16:28.38 |
| | where $(SAN_EXE) will be empty in non sanitizer builds, and "-" in sanitizer ones. So make will ignore the return value and continue. | 16:29.09 |
| HenryStiles | Robin_Watts: right that will work, but I'd like everything to build cleanly. I hope we don't use that to get around fixing genconf and romfs | 16:30.21 |
| Robin_Watts | HenryStiles: Oh yes, this would be a hacky fix. | 16:31.07 |
| kens | HenryStiles : Did you mean to change the assignment of 696447 to me ? | 16:32.20 |
| | HenryStiles : also earlier you suggested I should look at 696314 for a simple indexed image, but that is a Staple PJL bug. THere is no test file there, so I'm kind of confused | 16:35.18 |
| HenryStiles | kens: yes and you can close it, I just wanted to make sure you noticed the message FirstPage > LastPage thinking it might have been unintionally introducess with your device subclass project | 16:35.51 |
| kens | Its always been there, the PDF interpreter doesn't use the subclass devices for FirstPage and LastPage, it does that iself. | 16:36.19 |
| | The file is so badly broken we can't find the Pages array I think. | 16:36.38 |
| HenryStiles | kens: okay then just close it. | 16:36.49 |
| kens | OK | 16:37.26 |
| HenryStiles | kens: right I didn't mean staple I meant the XL -> PDF problem which I assigned to you | 16:37.41 |
| kens | I don't see that | 16:38.00 |
| | What's the number ? | 16:38.09 |
| HenryStiles | http://bugs.ghostscript.com/show_bug.cgi?id=696224 | 16:38.30 |
| kens | Ah OK its back in the list, behind all the latest sanitizer and Robin bugs | 16:38.56 |
| HenryStiles | I have no idea why Hin-Tak goes on and on in the bug without simply looking at the XL code which he does understand well | 16:39.59 |
| kens | possibly because he does that all the time...... | 16:40.17 |
| | Oh good grief, I remember ths bug report. | 16:43.02 |
| | Did you try running the PXL to any other devices Henry ? WHen I did that I got incorrect results for many of them | 16:43.22 |
| HenryStiles | x11 and ppmraw work | 16:46.13 |
| kens | tiff32nc ? | 16:46.24 |
| Robin_Watts | HenryStiles: haha, simpler fix is to make the recursive make invocation of the sanitize targets pass -i :) | 16:46.28 |
| kens | HenryStiles : I see random miscolored text using the Windows display device, in particular a black character on page 2 | 16:48.03 |
| HenryStiles | kens: pcl doesn't even "tiger" with a cmyk device | 16:48.09 |
| kens | Well I see a problem with the Windows display device | 16:48.29 |
| HenryStiles | kens: default color model? | 16:49.46 |
| kens | yes | 16:49.50 |
| Robin_Watts | HenryStiles: How do you feel about this as a "fix" for bug 696603 ? http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=1386dbd1ad0bef6b6264e198162d0b7c9abfce54 | 16:50.44 |
| | And chrisl, when you return, how do you feel about: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=b229184fdfa13b29ace5106bc34677a17c7da7f5 | 16:51.12 |
| kens | Well I will look at it again, but I'm not convinced this is a pdfwrite problem | 16:51.13 |
| HenryStiles | kens: I'll narrow it down some more if you like. | 16:51.59 |
| | Robin_Watts: yeah fine by me. | 16:52.08 |
| kens | I've never tried to debug it, because it didn't work 'orrectly'when I viewed it on Windows. | 16:52.38 |
| HenryStiles | kens: does the windows device show the first characters as black? | 16:52.50 |
| kens | No, but it shows a black character on page 2 | 16:53.03 |
| | which is apparently supposed to be all red | 16:53.17 |
| HenryStiles | kens: baffling this is very simple stuff. | 16:55.36 |
| | no rops or transparency | 16:55.48 |
| kens | Not a lot I can say | 16:55.49 |
| | Well pdfwrite is producing a page for page 1 where the4 Indexed space has a base space of DeviceGray. I would imagine that's why its black | 16:56.50 |
| HenryStiles | I'll take it back and take the file apart now I'm curious | 16:58.03 |
| kens | I've started looking at it | 16:58.12 |
| | While I wait for something else | 16:58.28 |
| HenryStiles | be back in a bit need some food | 17:00.01 |
| kens | HmmI may see what's going on with pdfwrite. | 17:04.44 |
| | Well the colour space I'm getting is an Indexed space with an ICC base space, and the base space of the ICC space is DeviceGray. So not unsurprisingly, that's what get's written to the output. THat's why the 'text' on page 1 is black. | 17:08.55 |
| chrisl | Robin_Watts: it seems a bit pointless putting in a new target for just a month or so | 17:18.05 |
| kens | HenryStiles : In pldraw.c pl_begin_image the gs_image_t *pim has a ColorSpace which does not match the current colour space, and is an Indexed DeviceGray | 17:18.08 |
| Robin_Watts | chrisl: Well, the targets would stay after the moment. Just the -i would go. | 17:18.28 |
| | s/moment/month/ | 17:18.34 |
| | My fingers have a life of their own. | 17:18.41 |
| | actually, we could commit just the targets and leave the -i out, and we could use -i manually for now. | 17:19.41 |
| kens | HenryStiles : Ths is set up by px_imaeg_color_space in pxgstate.c That sets the pim->ColorSpace by doing a switch on params->color_space, and that is set to eGray | 17:20.17 |
| chrisl | Robin_Watts: Just doing "make XCFLAGS=-fsanitize=address -fno-omit-frame-pointer" seems easy enough | 17:20.50 |
| Robin_Watts | chrisl: Except that doesn't work. | 17:21.01 |
| kens | I'm not at all certain how that comes out coloured in other devices, but its not going to come out in anything except DeviceGray with pdfwrite. | 17:21.01 |
| Robin_Watts | At best you need to fiddle with LDFLAGS too | 17:21.14 |
| | But if you're against it, fair enough. | 17:21.33 |
| | I prefer the option of having this stuff build into a separate dir. | 17:21.50 |
| chrisl | Robin_Watts: Your commit doesn't touch LDFLAGS | 17:21.59 |
| Robin_Watts | Does too. | 17:22.06 |
| | (assuming you're looking at the latest one) | 17:22.21 |
| chrisl | Oh, you use a CFLAGS in LDFLAGS..... | 17:22.40 |
| Robin_Watts | I use CFLAGS_SANITIZE, yes. | 17:22.53 |
| | If you'd rather not take it on, I understand. I can just keep it kicking around in my git history. | 17:23.36 |
| chrisl | Give me a few minutes | 17:24.14 |
| kens | HenryStiles : if I hack the code so that params->color_space is eRGB then the text is no longer in black. Its not right either mind you. | 17:25.23 |
| chrisl | Robin_Watts: well, "make XCFLAGS="-fsanitize=address -fno-omit-frame-pointer" XLDFLAGS="-fsanitize=address -fno-omit-frame-pointer" works. | 17:28.25 |
| Robin_Watts | chrisl: It does, yes. | 17:28.44 |
| | (if you run it several times, and if don't mind it trampling over the bin dir, and if you don't want debug info) | 17:29.11 |
| | make XCFLAGS="-fsanitize=address -fno-omit-frame-pointer" XLDFLAGS="-fsanitize=address -fno-omit-frame-pointer" debug -i | 17:29.41 |
| chrisl | I'm using my branch with the genarch and mkromfs fixes | 17:30.09 |
| Robin_Watts | That version *should* work without retrying and with debug info. | 17:30.17 |
| | but personally I'd prefer the sanitizer builds go into sanbin/sanobj etc. | 17:30.37 |
| | It's all a question of convenience. | 17:30.47 |
| | But seriously, don't worry if you don't like it. I can keep it in my git repo. | 17:31.07 |
| chrisl | Robin_Watts: No, it's fine. The only thing I'd prefer is to have a separate LDFLAGS_SANITIZE rather than reuse the CFLAGS_SANITIZE (even if, in the top Makefile, LDFLAGS_SANITIZE=$(CFLAGS_SANITIZE) | 17:34.34 |
| Robin_Watts | chrisl: I have no problem with that. | 17:34.48 |
| | Want me to do that, or would you rather ? | 17:35.25 |
| chrisl | Robin_Watts: you go ahead, since you have it pretty much done | 17:35.50 |
| Robin_Watts | chrisl: ta. | 17:35.57 |
| chrisl | Robin_Watts: I guess ideally we *ought* to check in configure if the compiler actually supports those options <sigh> - but not today, I think | 17:38.23 |
| HenryStiles | kens: this isn't possibly related to the changing indexed color space that we visited in PCL? | 17:42.39 |
| kens | I don't thnk so, at least not directly | 17:42.58 |
| | THe PXL interpreter is sending an image with a ColorSpace which boils down ot /Indexed /DeviceGray, there's no way pdfwrite will ever produce anything except black output for that | 17:43.42 |
| | I don't understnd how anything else does either mind you | 17:43.56 |
| | Unless, of course, the PXL interpreter was to change the base space of the colour space *after* begin_typed_image and before rendering the image | 17:44.44 |
| | Which would be braodly a similar problem to the palette changing of course | 17:45.18 |
| tor8 | mvrhel_laptop: pdf_add_cid_font_widths can't possibly work... you read the glyph->metrics.horiAdvance without loading the glyph... | 17:48.43 |
| mvrhel_laptop | tor8: hold on | 17:50.50 |
| | let me look I tested all of this | 17:50.56 |
| tor8 | font->width_table is most likely never NULL on pdf inputs | 17:51.32 |
| mvrhel_laptop | tor8: ok so are we in pdf_create_cid_widths? | 17:53.14 |
| | I am a little confused where you are | 17:53.41 |
| tor8 | yes (I renamed it, but that's the function) | 17:53.44 |
| mvrhel_laptop | tor8: hmm. I think where I had tested that part of the code, was from mutool create | 17:55.07 |
| | which is no longer being done | 17:55.18 |
| | since we went to using the simple font only for that case | 17:55.27 |
| | and that would explain the spacing issues I was having | 17:55.54 |
| | :) | 17:55.59 |
| | in that case | 17:56.04 |
| | so we can probably remove that | 17:56.23 |
| tor8 | mvrhel_laptop: okay, I've got a half dozen commits on tor/pdf_create if you could give them an eye? | 17:56.34 |
| mvrhel_laptop | ok | 17:56.40 |
| tor8 | I tried to split them up so to one change per commit. | 17:57.24 |
| mvrhel_laptop | wow. ok. this will take a minute.... or two | 17:59.48 |
| | tor8: ok. well you did that all about 10x faster than I could have | 18:15.44 |
| | I feel a little silly about the misspell of descendant and not thinking of using pdf_to_num instead of the res structure that I made | 18:16.21 |
| | The only comment I had was should fz_new_buffer_from_shared_data call fz_new_buffer_from_data to reduce code? | 18:16.41 |
| | Also, wondering why not deflate the font stream? | 18:17.17 |
| | or do you have another plan for that | 18:17.26 |
| Robin_Watts | I'm not sure we ever deflate anything in mupdf :) | 18:18.09 |
| | oh, we do. | 18:18.40 |
| tor8 | mvrhel_laptop: I'd rather see the pdf writing code deflate streams automatically than have the users do it everywhere | 18:27.07 |
| mvrhel_laptop | tor8: sounds good | 18:27.29 |
| Robin_Watts | tor8: The only problem with that is if we want to hold the file open for a while before writing it. | 18:28.09 |
| | (I don't disagree with you though, just noting the downside) | 18:28.32 |
| tor8 | pdf_write_options.do_deflate? | 18:28.41 |
| Robin_Watts | yeah. | 18:28.59 |
| tor8 | Robin_Watts: well, in this case the buffer will just be a refcounted pointer to the buffer already in the fz_font or image | 18:29.42 |
| Robin_Watts | fair enough. | 18:29.57 |
| tor8 | so compressing it would actually make memory use worse :) | 18:30.01 |
| | biab, dinner | 18:30.11 |
| Robin_Watts | ah, hell. bug 696611 is back to a problem I thought I'd solved already. | 18:30.50 |
| | When the image enumerators call around to say "who can handle this image", I have to look to see if it's an imagemask, and if so, if I want to offer to interpolate it. | 18:31.42 |
| | I can't back out of that decision later, so I need to get it right. | 18:32.14 |
| | In order to be able to interpolate an imagemask, I need to have a device that can copy_alpha. | 18:32.38 |
| | Unfortunately, if I'm going to a clist device, it always offers a copy_alpha entrypoint, even if the underlying device does not. | 18:34.09 |
| | In this case, the underlying device is a 1bpp image, which does not offer copy_alpha. | 18:34.33 |
| | or rather, it offers default_copy_alpha, which relies on getbits and/or getbits_rectangle, both of which are default. | 18:36.26 |
| | so it won't work. | 18:36.33 |
| rayjj | Robin_Watts: so will a spec_op that the clist device forwards to its target work ? | 18:39.46 |
| | Robin_Watts: 'can_copy_alpha' | 18:40.11 |
| Robin_Watts | rayjj: Yes, that would work, except it means that we need to retrofit that to every device. | 18:40.34 |
| rayjj | Robin_Watts: every device that does support real copy_alpha | 18:41.12 |
| Robin_Watts | If we're going down that route, then I have 'nointerpolateimagemasks' param already defined. | 18:41.29 |
| | and I can get_param that. | 18:41.37 |
| rayjj | Robin_Watts: yeah, except get_params can be slow | 18:41.52 |
| Robin_Watts | get_param, not get_params. | 18:41.59 |
| | but yes. | 18:42.11 |
| rayjj | Robin_Watts: yeah, getting a single param is probably no more overhead than spec_op | 18:42.41 |
| Robin_Watts | ken implemented a gxdso that does a get_param. | 18:42.59 |
| | And it requires nasty duplication of code, but it's faster than get_params. | 18:43.23 |
| | It's also unsafe by design, but that's another argument. | 18:43.37 |
| rayjj | Robin_Watts: the nointerpolate could be moved to the dev structure so you can interrogate it directly, | 18:43.42 |
| Robin_Watts | It could. | 18:44.02 |
| rayjj | or color_info where the anti_alias values are carried | 18:44.28 |
| | either one requires it to be set in compositor devices. | 18:46.15 |
| Robin_Watts | yeah. | 18:46.51 |
| | I have an alternative way to work, but I dislike that just as much. | 18:47.15 |
| rayjj | Robin_Watts: all this is to add an optional feature to interpolate masks as Adobe does (that the spec doesn't require), right ? | 18:48.08 |
| Robin_Watts | (namely that we should only populate device_procs with the clist_copy_alpha if the underlying device was copy_alpha capable. | 18:48.14 |
| | rayjj: Yes. | 18:48.17 |
| | I think I may just update the image1 device to nointerpolateimagemasks. | 18:48.39 |
| rayjj | Robin_Watts: I see, so that places the burden on the clist device setup., which is infrequent, and already complex | 18:48.56 |
| Robin_Watts | rayjj: Yes. | 18:49.11 |
| | I vaguely like the idea of "wrapping devices shouldn't offer functions that the underlying device didn't offer" | 18:49.39 |
| | but then that goes against the principle that "all procs will be filled in, by gs offering defaults if necessary" | 18:50.16 |
| rayjj | well, yes, but that's the whole point of something like the pdf14 compositor -- to provide transparency that other devices don't | 18:50.26 |
| Robin_Watts | rayjj: I may have expressed that badly. | 18:51.00 |
| rayjj | and if the wrapper is the pdf14 device, then it _can_ support real copy_alpha, even if the target is 1bpp | 18:51.07 |
| Robin_Watts | yeah. OK, so "wrapping devices shouldn't offer functions that the underlying device didn't offer, unless it's the wrapping device that's offering those functions" | 18:51.45 |
| rayjj | Robin_Watts: better | 18:51.54 |
| Robin_Watts | Essentially, I'd be taken with the idea of a proc being NULL meaning "don't call this, I can never cope", but that goes directly against the existing stuff. | 18:52.44 |
| rayjj | Robin_Watts: for the most part. Like English, most "rules" in gs have exceptions. put_image comes to minf | 18:53.22 |
| | s/minf/mind/ | 18:53.29 |
| | we (mvrhel) could have refactored the pdf14_put_image to move the "construct an image and feed it to the device" code for the put_image proc == NULL case to a gx_default_put_image proc | 18:55.00 |
| | and for better consistency, we probably should | 18:55.23 |
| Robin_Watts | Of course, maybe 1bpp devices *should* support copy_alpha these days. | 19:00.27 |
| rayjj | Robin_Watts: the problem is painting gray (halftoned) data over existing data on the page that may have been painted | 19:07.01 |
| Robin_Watts | rayjj: Not sure I follow. | 19:09.07 |
| rayjj | Robin_Watts: will it reasonably match what is gotten by rendering gray, then post-halftoning | 19:09.08 |
| Robin_Watts | I'm running a cluster test now. We can see when it completes :) | 19:09.32 |
| rayjj | if you paint an black with 50% alpha on white, you get 50% gray, if you have a background that was already painted with 50% gray then halftoned, then how do you compute the result from | 19:11.13 |
| malc_ | rayjj: you'd get 100% gray perhaps? | 19:11.39 |
| rayjj | malc_: more likely 50% gray since the halftone bits "line up" | 19:12.04 |
| malc_ | uhm.. okay, sounds weird though... black 0/0/0 white 1/1/1 blend 50%, .5/.5/.5 == gray, but i clearly don't know anything about colours | 19:13.18 |
| rayjj | the 1bpp operation would compute the halfoned bits it wants to paint, using the source alpha+color, get 50%, then halftone it, and "or" the bits, so no new bits would appear | 19:13.26 |
| Robin_Watts | rayjj: I hope it would work out on average. | 19:14.17 |
| rayjj | essentially you'd get the darker of the source and destination | 19:14.18 |
| | Robin_Watts: it might if the halftone patterns were not correlated | 19:14.59 |
| | but they usually are | 19:15.10 |
| | Robin_Watts: unless you are deriving a gray value from the bits that are on by examining an area, and that breaks if the contents were painted as small black features (i.e., lines) | 19:18.08 |
| | this element with small black features would be preserved on a gray device, but any derivation of "local gray" would result in them being (partially) erased when painted over by an alpha paint operation. | 19:20.02 |
| | Just or-ing the bits preserves the underlying small features, but then the alpha blending doesn't work | 19:20.39 |
| | Robin_Watts: if by "works out on average" you mean files that look worse vs. files that look better, well, maybe... | 19:24.22 |
| Robin_Watts | ok, so that bmpcmp is fairly convincing :) | 19:26.39 |
| | I may just disable interpolation of imagemasks for 1bpp output devices. | 19:27.06 |
| rayjj | Robin_Watts: 1 bit per component. Actually, I recommend *ANY* device that need halftoning (we use < 4 bits per component for that elsewhere( | 19:30.05 |
| | Robin_Watts: there is a gx_device_must_halftone | 19:31.24 |
| | (macro, of course) ;-/ | 19:31.48 |
| Robin_Watts | We enable copy_alpha for any device with more than 1 bit, as far as I can tell. | 19:31.50 |
| rayjj | once previously painted data has been halftoned, any alpha blending will be wrong (most of the time) | 19:33.02 |
| | Robin_Watts: in that it won't match what would come from rendering to contone, then halftoning the page | 19:35.33 |
| Robin_Watts | indeed not. | 19:36.12 |
| | I'll try it both ways and we can compare. | 19:36.22 |
| | rayjj: So, the bmpcmp there now is for "don't interpolate imagemasks to 1bpc" | 20:04.52 |
| | Given that we allow copy_alpha to pkmraw, I'm not sure I see the harm in allowing interpolation. | 20:13.25 |
| | If we simple "don't interpolate imagemasks when going to 1bpp" we get no bitmap differences at all (but it solves the bug). | 20:14.20 |
| | Trying the "don't interpolate when halftoning" now. | 20:15.21 |
| tor8 | Robin_Watts: mvrhel_laptop (for the logs): terribly sorry, but I couldn't resist rewriting pdfcreate.c into something a bit more suited as an example of how to use the code | 20:28.31 |
| | mvrhel_laptop: code is on tor/pdf_create | 20:28.55 |
| | mvrhel_laptop: I must say, this new font resource creation, and how it automatically finds duplicates is awesome! | 20:29.46 |
| | this should definitely make it into the release, IMO | 20:30.16 |
| Robin_Watts | rayjj: Ha! For the purposes of cluster testing, "don't interpolate when halftoning" == "don't interpolate to 1bpc" :) | 20:42.12 |
| | tor8: "Always write a newline after pdf_print_obj" | 20:44.23 |
| | Why then do you print "\nstream\n" in expandstream? | 20:44.44 |
| | and in writeobject? | 20:45.05 |
| | oh, sorry, I misread what you meant. Ignore that. | 20:45.39 |
| | tor8: For the "Skip the newline" commit, shouldn't we test buf->len > 0 ? | 20:47.18 |
| | Other than that, the first 3 commits look good. | 20:47.31 |
| sebras | http://xkcd.com/1647/ pårtäble döcument förmåt! | 21:18.15 |
| malc_ | tù mâny dïâçrîtïcs | 21:21.46 |
| sebras | malc_: as I read the wikipedia page on diacritics either slovakian or livonian appears to win the contest. perhaps welsh, but it was a bit unclear. | 21:23.05 |
| malc_ | sebras: wrong - vietnamese! | 21:23.47 |
| | ï·½ | 21:23.55 |
| | is unbeatable though | 21:24.02 |
| sebras | malc_: that was my first idea, but wikipedia didn't really describe it very well. | 21:24.26 |
| | malc_: I'm surprised that this is a single ligature in unicode! | 21:25.51 |
| malc_ | i think theres a shahadah ligature in there somewhere too | 21:26.18 |
| | Arabic supplement A i think covers it | 21:26.28 |
| sebras | malc_: arabic presentation forms-a wikipedia told me. | 21:26.55 |
| malc_ | yep, that's it | 21:27.01 |
| sebras | malc_: not that I know the difference (yet). | 21:27.04 |
| malc_ | sebras: and vietnam wins the contest simply due to tonal nature (7 i think) | 21:27.44 |
| | all the cedilias, tremas, umlauts etc are just kids | 21:27.57 |
| | now tones! | 21:28.06 |
| rayjj | Robin_Watts: I saw the comments about "must_halftone" vs. 1 bpc. I'm not surprised, but still recommend the (somewhat more consistent) gx_device_must_halftone. AFAICT, that works whether or not we are in clist mode, and also with the pdf14 compositor since it is based on color_info | 21:36.02 |
| | and the clist device uses the target's color_info, while the pdf14 device has its own color_info | 21:36.48 |
| | malc_: so, what we need is unicode for music _and_ choreography (or does that already exist?) | 21:46.15 |
| malc_ | rayjj: music - certainly, choreography.. PUA :) | 21:47.10 |
| | 1D14DMusical Symbols1D100 | 21:48.24 |
| | 1D24FAncient Greek Musical Notation1D200 might come in handy too | 21:48.57 |
| | to please the olympians or something | 21:49.06 |
| sebras | rayjj: with the recent color font standards I wonder if we'll get codepoints that define color usage in the glyphs. | 21:51.41 |
| malc_ | emojii already made it into unicode, colours are the next logical step, with le déluge following shortly | 21:53.36 |
| terry__ | Is there an iOS based library that can convert old-fashioned PostScript files into PDFs? I want to build the functionality of ps2pdf into my iOS app. | 23:41.34 |
| Robin_Watts | malc_: There are already 'modifiers' in unicode that change the color of emoji. | 23:42.29 |
| | terry__: postscript -> pdf requires a postscript interpreter. | 23:42.51 |
| | thus something like ghostscript (for the general case at least). | 23:43.06 |
| | You can build gs on ios. | 23:43.15 |
| | as a lib. | 23:43.22 |
| tor8 | Robin_Watts: yeah, we should test buf->len. fixed commit up now. | 23:43.33 |
| terry__ | Robin_Watts: Thank you. Do you know if someone has packaged that up nicely somewhere, or would I have to start from scratch? | 23:44.06 |
| Robin_Watts | terry__: You'd have to start from scratch. but it shouldn't be too hard (other than having to deal with the usual xcode shite) | 23:44.41 |
| | tor8: The first 3 commits look good to me then. | 23:44.58 |
| | I haven't looked at michaels, but I assume you have. | 23:45.09 |
| tor8 | Robin_Watts: thanks. | 23:45.12 |
| terry__ | Robin_Watts: OK, thanks | 23:45.39 |
| tor8 | yes; I've gone through and done a tor-style-filter pass and that's the stuff after michael's so if one or both of you could review that would be swell | 23:45.48 |
| Robin_Watts | tor8: probably best for michael to review that. | 23:46.04 |
| | I'll try to squash the entire branch tomorrow and look over the squashed version. | 23:46.16 |
| tor8 | Robin_Watts: yeah. I haven't looked at the pdf-device changes in all that much detail. | 23:46.34 |
| | Forward 1 day (to 2016/02/25)>>> | |
IRC Logs