| | <<<Back 1 day (to 2013/05/19) | 2013/05/20 |
| vtorri_ | tor8, i've solved my rendering problem, just a missing call of an evas function | 07:22.13 |
| | now, i display the pdf | 07:22.48 |
| tor8 | vtorri_: great! | 07:36.38 |
| vtorri_ | tor8, but now, i'm wondering if I use dislay_list correctly :) | 07:37.23 |
| Robin_Watts | vtorri_: | 08:34.55 |
| | You want something like: if (pagenum != the_page_number_the_display_list_is_for) { fz_free_display_list(list); list = NULL; } | 08:35.56 |
| | if (displaylist == NULL) { regenerate_display_list... } | 08:36.19 |
| vtorri_ | Robin_Watts: in _etui_pdf_page_set() i guess | 08:38.43 |
| | "the_page_number_the_display_list_is_for" <--- the current page number i guess | 08:40.04 |
| Robin_Watts | vtorri: Yes. The point is you want to throw away the old page whenever you render a new one. | 09:08.08 |
| vtorri_ | indeed | 09:08.19 |
| | thank you | 09:08.24 |
| Robin_Watts | np. bbiab. | 09:08.33 |
| vtorri_ | Robin_Watts: actually, i already free the display list | 10:21.54 |
| | https://github.com/vtorri/ecrin/blob/master/etui/src/modules/pdf/etui_module_pdf.c#L331 | 10:22.13 |
| | i reach that line if the pages are different | 10:22.29 |
| | so i just have to create one just after the free, line 335 | 10:22.55 |
| | right ? | 10:22.58 |
| Robin_Watts | vtorri: So, you're freeing the page on every page_set. Fair enough. | 10:31.41 |
| | but in render, if you're using the display list you ALWAYS re-render it. | 10:32.15 |
| | You want to only render it if you haven't got one already. | 10:32.27 |
| | if (pd->page.use_display_list && !pd->page.list) { dev = ... } | 10:32.58 |
| vtorri_ | hmm | 10:39.49 |
| | ok | 10:39.51 |
| | thanks | 10:39.59 |
| Robin_Watts | Can anyone else get to peeves? | 11:21.35 |
| | ah, dashboard shows it as down. | 11:21.47 |
| henrys | kens:I never actually looked at the code, setcharwidth ends up calling setcachedevice? weird you use setcharwidth when you don't want to cache the character right? | 13:39.14 |
| kens | henrys it goes through the pdfwrite text_set_cache which strictly speaking isn't quite the same thing, but it works for my purposes | 13:39.51 |
| henrys | okay | 13:40.12 |
| | kens:now that I look the intellifont build_char routine uses the 0 area setcachedevice as you had it. | 13:44.07 |
| kens | Hmm, well I'mhappy with this, or can change it to setcachedevice. For me its the same either way | 13:44.57 |
| henrys | kens:I might change the intellfiont thing someday, I do prefer setcharwidth ... | 13:46.05 |
| kens | Fair enough | 13:46.41 |
| Robin_Watts | henrys: I made mudraw output pwgraster last week. | 14:01.54 |
| | I'm pondering how hard it would be to add pcl output too, by just dumping bitmaps. | 14:02.33 |
| | How hard would it be to write a PCL file that consisted of (possibly rle'd) bitmap rgb data (or grayscale or mono) | 14:03.27 |
| | ? | 14:03.30 |
| henrys | Robin_Watts: trivial pull it out of ghostscript | 14:03.50 |
| Robin_Watts | 2 halves of a sentence that are seldomly seen in conjunction there... | 14:04.19 |
| | :) | 14:04.20 |
| | can you point me at the appropriate device please? | 14:04.40 |
| henrys | the problem is printer options - how are you doing say duplex, paper requests - all the setpagedevice stuff? | 14:04.40 |
| Robin_Watts | henrys: For the first version, I'm not. | 14:04.55 |
| henrys | ljet4 is very easy. | 14:05.04 |
| kens | You can't set those (driectly) in PDF anyway, nor in XPS | 14:05.16 |
| Robin_Watts | My plan with such things is to have an options struct that can be passed into the function. | 14:05.26 |
| | The default code will pass NULL. | 14:05.34 |
| kens | Both require a separate job descriptor | 14:05.41 |
| Robin_Watts | so people can fill the struct out if the want to use it. | 14:06.09 |
| henrys | well I thought thought pwgraster was to work with ppd's like cups? | 14:06.22 |
| Robin_Watts | Right. | 14:06.27 |
| | So there will be a separate exe for that, that understands all the extra command line things to pass in the various options. | 14:06.57 |
| | That will fill in the options struct and pass it in to the writing code. | 14:07.09 |
| | so mudraw doesn't get bogged down in such things. | 14:07.42 |
| henrys | you can do color but I don't know of any performant laser color using PCL raster, you have to use high level xl which is something you don't want to get into. | 14:11.30 |
| Robin_Watts | henrys: Step 1 is to get *something* that works, I think. | 14:12.50 |
| | We could do a high level output device later, but that would have issues with transparency etc. | 14:13.22 |
| | Presumably, if you are printing full page photos, you must be sending raster, right? | 14:14.05 |
| henrys | I shouldn't have said non performant - I mean unacceptable or doesn't work at all (memory overflow) | 14:15.01 |
| | so if you are going with raster I'd say do mono | 14:15.31 |
| Robin_Watts | henrys: I'll do both, assuming it's not stupidly hard. | 14:15.51 |
| | but are you seriously saying that people might buy a color laser printer, and when they try printing a photo on it, be told that it's run out of memory? | 14:16.30 |
| | How can people print a full page color photo in PCL *without* sending raster? | 14:17.27 |
| henrys | Robin_Watts:pxlcolor, ps2write, pswrite | 14:17.57 |
| | Robin_Watts:oh sorry misunderstood - I doubt it would be able to print a 600 dpi high level image. | 14:19.14 |
| Robin_Watts | If I was testing a laser printer, my tests would be: 1) black and white text, 2) color text, 3) office graphics (text, line art etc), 4) full page photos. | 14:19.33 |
| henrys | I think postscript would fail as well, typically images are smailer and scaled to 600 or 1200 dpi. | 14:19.46 |
| | but your photos aren't 600 dpi | 14:20.08 |
| kens | PostScript, it depends on teh printer and the VM | 14:20.42 |
| Robin_Watts | henrys: 18Megapixel camera on the floor next to me... | 14:21.04 |
| kens | In general the size o the input image ios not relevant, as only one scan line at a time is considered, and rendered to the output page | 14:21.06 |
| Robin_Watts | so 300dpi | 14:21.11 |
| | at A4. | 14:21.15 |
| kens | In a treaming langguage, the size of the input image is irrelvant (mostly) | 14:22.04 |
| Robin_Watts | kens: depends on the capabilities of banding, and the transform on the image etc, but... | 14:22.27 |
| kens | Yes, but in general we only need consider one scan line of the image | 14:22.41 |
| | So it doesn't matter how big the input image is, we only look at one scan line at a time. (barring things like clever downsampling and so on) | 14:23.17 |
| | Of course, it can take a long time to transmit the image data, and thenfor the interpreter to throw it away.... | 14:24.04 |
| henrys | I am almost certain a 600 dpi postscript image (full page) will choke my Color Laserjet 4600 - which is a fairly good color laser. | 14:24.26 |
| kens | But perhaps a crappy PostScript interpreter ? THere really is no need for the interpreter to store very much of the image data | 14:24.57 |
| henrys | if it doesn't choke it will take an eternity. I guess it would be easy to try it out if you like. | 14:25.01 |
| kens | I would beleive it will take a long time | 14:25.14 |
| henrys | the scan lines don't matter - printers work with bands they fill the bands with commands that get played back when the page is rendered. if you have bands full of raster commands for an entire page the printer is likely to run out of memory. | 14:30.52 |
| | Robin_Watts:any clj_print_page() is for color pcl raster - I'm happy to try out anything you produce on the Color Laserjet which is a fairly popular laser if not a bit dated. | 14:33.38 |
| | s/any// | 14:34.05 |
| Robin_Watts | henrys: Thanks. I will try that out later. Just adding the PWG options struct now. | 14:34.25 |
| kens | Err, that's *one* way for a printer to work. ANotehr is as a page device where it simply renders directly to memory. | 14:34.55 |
| henrys | kens:absolutely if it is full frame there is no issue. | 14:35.41 |
| kens | So the size of the input is irrelevant, the printer has enough memory for the whole page, and only needs enough additional memory to handle interpretation. | 14:35.49 |
| | Another technique is 'compressed raster' where we store the whoel page in compressed form, and only decompress sections as required. More efficient on memory but slower, and in extreme cases may actually run out of memory if the total available is less than a full uncompressed page | 14:36.44 |
| henrys | I don't know of full frame color printers, ray_laptop would be out of business if it were the norm. | 14:37.23 |
| | all our printer customer have used the command list as far as I know. | 14:39.14 |
| kens | Well, we implemented teh compressed raster method for a Jaws customer. I know of others who used a page buffer directly. I couldn't say how many were colour, or laer printers though | 14:40.30 |
| | To me the clist method sounds like the wrost of all worlds, but <shrug> I haven't analysed it | 14:41.10 |
| | IIRC chrisl got Jaws running full colour A4 in the same memory footprint as the original Apple LaserWriter. | 14:42.26 |
| | Admittedly very slowly, and prone to run out of memory at the slightest provocation, but then its 'dancing bear' territory | 14:42.57 |
| Robin_Watts | clist wins if you have a harddisc, but small ram. | 14:43.33 |
| henrys | kens:what if you want to render ahead of the current page? | 14:43.41 |
| kens | Yes, but that's not usually the case for printers | 14:43.47 |
| Robin_Watts | kens: Indeed. | 14:43.58 |
| kens | henrys, again, these kinds of devicesw usually have enough memory for a full pahe in my experience | 14:44.31 |
| | s/pah/page/ | 14:44.39 |
| Robin_Watts | kens: In the absence of transparency that's absolutely sane. | 14:44.59 |
| | But with transparency there is a swing back towards clist again. | 14:45.14 |
| kens | Possibly, I haven't really been in touch with low level manufacturers in recent years. | 14:45.36 |
| | As far as I'm aware, most printers still don't do PDF as an input, which leaves raster ops, and area I know nothing about | 14:46.26 |
| Robin_Watts | raster ops is easy to do pagewise. | 14:46.50 |
| kens | Given that you have to do the rendering at some point, it seems to me that a page buffer should always be the fastest approach. Barring multiple rendering threads | 14:47.44 |
| henrys | Robin_Watts: marcosw also has a similar printer so probably best to stick with that, you'll have 2 folks to test. | 14:48.11 |
| | kens:the laters lasers are 1200 dpi some with multiple bits per component that's a lot of memory | 14:51.24 |
| kens | Memory is cheap | 14:51.40 |
| | And yes I know manufacturers liek to economise on it | 14:51.55 |
| | But they also like a decent PPM | 14:52.10 |
| henrys | Robin_Watts: FWIW monochrome PCL raster works fine on my color printer. | 14:59.01 |
| Robin_Watts | henrys: Thanks. | 14:59.27 |
| henrys | humph henrysx6 is not reachable. | 15:33.15 |
| ray_laptop | the network connection from peeves appears VERY busy | 16:34.43 |
| Robin_Watts | ray_laptop: peeves has been down as far as the cluster is concerned all day | 16:39.15 |
| henrys | I've rebooted henrysx6 and it is up now, no idea what happened | 16:43.09 |
| ray_laptop | robin_watts: OK. restarting peeves (the old fashioned way). But why that would make the other machines on my local network slow, I don't know | 16:49.46 |
| | I couldn't get in locally | 16:50.41 |
| | it may take a while to come back u | 16:50.59 |
| | up | 16:51.01 |
| | well, actually it is up now. | 16:52.00 |
| | That was FAST | 16:52.03 |
| | must have been something peeves was doing to the net that was making it slow. It's fast now | 16:54.17 |
| vtorri_ | you guys seem to like Harry Potter a lot :p | 17:30.41 |
| | Robin_Watts: about my lib, in page_set(), i free the page and the display_list, and i create a new page and a new display_list | 17:32.47 |
| | is it reasonnable ? | 17:32.55 |
| ray_laptop | vtorri_: our primary server is actually 'casper', but for a while we had our DNS secondary server named 'nick' (it was a laptop with a bad screen, so it was a play on "Nearly Headless Nick") | 17:58.57 |
| | but once we got the regression cluster going, we got tired of naming them after ghosts | 17:59.35 |
| | The names of our regression servers follow from one of the first AMD servers "miles" named after our president. Then marcosw followed in the distance terms since there are lots to pick from. | 18:00.52 |
| | a few of our regression servers, however, are named after the staff member who has them. | 18:01.40 |
| Robin_Watts | vtorri: Our names, AFAIK, have absolutely NOTHING to do with HFP. | 18:10.36 |
| sebras | Robin_Watts: its HJP, is it not..? | 18:13.22 |
| | even with an apostrophe... | 18:13.39 |
| Robin_Watts | sebras: The F is not his middle name :) | 18:13.45 |
| sebras | Robin_Watts: oh. so it's french. :) | 18:15.23 |
| | just for the record, I had to look up the J... | 18:16.04 |
| vtorri_ | junior ? | 18:17.56 |
| | Robin_Watts: and about my question ? | 18:18.19 |
| Robin_Watts | vtorri: Urm, assuming you never call set without then calling render, that's fine. | 18:18.49 |
| | as otherwise you'd be wasting time. | 18:18.57 |
| ray_laptop | robin_watts: you will be pleased that we've abandoned the ghost naming, but had we continued, I wasn't going to name any of my machines from H F* P | 18:20.02 |
| Robin_Watts | ghost naming didn't offend me. | 18:20.36 |
| ray_laptop | when rillian had his fanless machine, I was going to suggest he name it 'whisperer' | 18:21.27 |
| Robin_Watts | :) | 18:21.35 |
| ray_laptop | but he didn't go for that. | 18:21.40 |
| vtorri_ | Robin_Watts: i don't really understand what you write above : if (pd->page.use_display_list && !pd->page.list) { dev = ... } | 18:24.08 |
| | that code should go in render | 18:24.30 |
| | i don't understand the !pd->page.list | 18:24.52 |
| | why ! ? | 18:25.07 |
| Robin_Watts | if (pd->page.use_display_list == if (we're using a display list | 18:25.50 |
| | && !pd->page.list) == && we haven't got a page list) | 18:26.14 |
| | then make one. | 18:26.24 |
| vtorri_ | i already do that | 18:26.36 |
| Robin_Watts | Right, but your existing code was wrong. | 18:26.48 |
| vtorri_ | ha ? | 18:26.55 |
| Robin_Watts | maybe you've fixed it since I looked. | 18:27.02 |
| | but your existing code said: | 18:27.19 |
| | if (pd->page.use_display_list) { if (!pdf->page.list) { make one } make_a_page_list_device; draw onto it; free the device; } | 18:28.18 |
| vtorri_ | yes | 18:28.40 |
| Robin_Watts | which meant that every time you entered render, you'd draw onto the display list again. | 18:28.41 |
| | "yes, that's what it used to do" or "yes, that's what I do and I can't see why that's wrong" > | 18:29.01 |
| | ? | 18:29.03 |
| vtorri_ | "yes, that's what I do and I can't see why that's wrong" | 18:29.15 |
| | and how to fix that :p | 18:29.33 |
| Robin_Watts | OK. The first time you render, you'll enter the render function. | 18:29.42 |
| | You'll see that you're supposed to be using a display list. | 18:29.56 |
| | You'll check to see if you've got a display list - you haven't, so you make one. | 18:30.11 |
| vtorri_ | yes | 18:30.23 |
| Robin_Watts | Then you make a display list device that writes to that list. | 18:30.29 |
| vtorri_ | 'write to that list' == 'draw onto it', right ? | 18:30.51 |
| Robin_Watts | Then you run the page. That appends a whole load of drawing operations onto the display list. | 18:31.02 |
| | A display list is a list of display operations. | 18:31.13 |
| | so writing to the list doesn't actually draw anything. It puts stuff onto the list so that when you play the list back to a drawing device, THEN drawing will be done | 18:32.00 |
| | ok? | 18:32.12 |
| vtorri_ | ok | 18:32.15 |
| Robin_Watts | So, the second time you render a page... | 18:32.25 |
| vtorri_ | so i guess that the "problem" is when i render the same page a second time | 18:32.35 |
| Robin_Watts | you check to see if you're supposed to be using a display list - and you are. | 18:32.49 |
| vtorri_ | yes | 18:32.53 |
| Robin_Watts | You HAVE a display list already, so you don't make another one. | 18:33.00 |
| vtorri_ | yes | 18:33.08 |
| Robin_Watts | You then make a list writing device with your existing display list. | 18:33.23 |
| | and you run the page to it. | 18:33.27 |
| | You now have 2 copies of the drawing operations for the page on your list. | 18:33.39 |
| vtorri_ | so the problem is that i have called fz_run_page() twice, right ? | 18:34.09 |
| Robin_Watts | Yes. | 18:34.28 |
| vtorri_ | hmm | 18:34.34 |
| | so | 18:34.43 |
| | actually, i can save the device | 18:34.53 |
| Robin_Watts | Why would that help? | 18:35.10 |
| vtorri_ | first render : i create the device | 18:35.12 |
| | because it is NULL | 18:35.22 |
| | then I call fz_run_page | 18:35.32 |
| Robin_Watts | You need the display list writing device when you write the display list. | 18:35.42 |
| vtorri_ | second call : as the device is not NULL, I do not call fz_run_page | 18:35.51 |
| Robin_Watts | You only need to write the display list once. | 18:35.53 |
| | ?!?!?!?!? | 18:36.18 |
| vtorri_ | :) | 18:36.28 |
| Robin_Watts | If you have a display list, then you don't need to do anything! | 18:36.33 |
| vtorri_ | no fz_new_list_device nor fz_run_page ? | 18:36.59 |
| Robin_Watts | EXACTLY! | 18:37.06 |
| vtorri_ | hmm | 18:37.21 |
| Robin_Watts | change the condition to be if(I_should_be_using_display_lists && I don't have one). | 18:37.29 |
| | i.e. exactly what I said many hours ago. | 18:37.39 |
| vtorri_ | so actually, i can call fz_new_list_device and fz_run_page during page_set(), right ? | 18:37.41 |
| | just after creating the display_list | 18:38.01 |
| Robin_Watts | sure, if that's what you want to do. | 18:38.07 |
| vtorri_ | they all will be called only once | 18:38.12 |
| | thanks | 18:38.58 |
| Robin_Watts | np | 18:41.32 |
| vtorri_ | may i call fz_free_device() just after fz_run_page() ? or should I keep the device ? | 18:44.12 |
| Robin_Watts | Get rid of the device as soon as you can. Why would you keep it around? | 18:46.34 |
| vtorri_ | i don't know | 18:46.58 |
| | you have realized that i don't know much all that stuff :) | 18:47.15 |
| ray_laptop | oops. That's not good. I wonder if peeves just crashed. (rayjj was running on peeves) | 18:47.24 |
| | hmm... I'm able to ssh in, but when I switch my KVM over to peeves, nada :-( | 18:48.52 |
| | I wonder if I have a heating problem ? | 18:49.08 |
| Robin_Watts | ray_laptop: can you take the side of the case off easily? | 18:49.45 |
| | tor8: We have a -g flag in mudraw to mean "render in grayscale" | 18:50.08 |
| ray_laptop | robin_watts: I'll look. It's been a while | 18:50.12 |
| Robin_Watts | How would feel about -gg meaning "monochrome" ? | 18:50.22 |
| tor8 | Robin_Watts: isn't there a flag for non-antialiased, and pgm output? | 18:50.55 |
| | pbm output, I mean | 18:51.02 |
| Robin_Watts | file.pbm means monochrome currently. | 18:51.16 |
| | and -a0 means no antialiasing. | 18:51.34 |
| | but that doesn't mean monochrome, cos you get greys etc, right? | 18:51.45 |
| tor8 | you want monochrome 1-bit output for png (and other formats that can support variable bit depths?) | 18:51.50 |
| Robin_Watts | For pwg and for png specifically | 18:52.03 |
| | and for pcl. | 18:52.06 |
| vtorri_ | robin_watts: i've updated the code | 18:52.12 |
| | fz_run_page is called only once, during page_set | 18:52.30 |
| Robin_Watts | For png you get rgb by default, -g means greyscale. I could add -SOMETHINGELSE for mono, or use -gg. | 18:52.45 |
| tor8 | Robin_Watts: a bit depth flag (with values 1 and 8 supported)? | 18:52.46 |
| vtorri_ | i've remove all the code in render(), as it's seless now | 18:52.59 |
| tor8 | if we want dithered rgb or cmyk out for instance | 18:53.16 |
| Robin_Watts | tor8: yeah, cmyk would be good. | 18:53.35 |
| | oops. It's -b for antialiasing, not -a. | 18:53.53 |
| ray_laptop | robin_watts: the CPU temps all look OK. The highest coretemp is 62C, the high limit is 80C, critical 100C | 18:54.00 |
| tor8 | maybe it's time to separate color/aa/depth from the output format | 18:54.03 |
| Robin_Watts | so want to suggest a flag ? | 18:54.16 |
| tor8 | have "default" values for each output format, and a validation step | 18:54.34 |
| | let me look over the current flags | 18:54.46 |
| | so we have colorspace, whether to save with or without alpha channel, bit depth and anti-aliasing flags | 18:55.51 |
| Robin_Watts | -c rgb8 ? | 18:56.20 |
| tor8 | how do you feel about splitting the text output to a separate tool so we can free up some options? | 18:56.39 |
| | and add more for the text output | 18:56.51 |
| ray_laptop | robin_watts: I stuck my hand inside the case, and it seems fine. I can't get at the video card easily. It might be the culprit | 18:56.52 |
| Robin_Watts | I'd rather avoid that, but... | 18:57.25 |
| ray_laptop | robin_watts: and nothing serious in kern.log. Do you know offhand of any other logs I should look at ? | 18:57.34 |
| tor8 | -c gray -c rgb -c cmyk ? | 18:57.38 |
| Robin_Watts | ray_laptop: I don't, sorry. | 18:57.55 |
| tor8 | -b for bit depth, -a for anti-aliasing | 18:58.04 |
| | rgba for rgb with alpha | 18:58.16 |
| Robin_Watts | I was hoping to avoid changing any existing flags. | 18:58.24 |
| | -c is free, and we can let that determine colorspace and colordepth | 18:58.41 |
| tor8 | -c <pixel format> basically | 18:58.55 |
| Robin_Watts | -c {mono,grey,rgb,cmyk} | 18:59.06 |
| | -c {mono,grey,rgb,rgba,cmyk} | 18:59.25 |
| tor8 | mono==grey (in my understanding of language) | 18:59.29 |
| Robin_Watts | grey = contone. | 18:59.41 |
| | mono = 0 or 1 | 18:59.46 |
| tor8 | monochrome = one color. monobit = 0 or 1. | 18:59.53 |
| ray_laptop | tor8: robin_watts: what's the objection to the more verbose options --color=rgb --bits-per-component=8, ... | 19:00.18 |
| Robin_Watts | ray_laptop: We haven't got code to handle --longflags :) | 19:00.59 |
| ray_laptop | or you could do like Russell Lang did with -dDisplayFormat=___ ;-) | 19:01.25 |
| | of course, we would drum you out of Artifex at the next staff meeting ;-) | 19:01.43 |
| tor8 | -c {mono,gr[ea]y,grayalpha,rgb,rgba,cmyk} is fine | 19:01.56 |
| | and drop -a | 19:02.24 |
| ray_laptop | robin_watts: you could probably lift the long-flags code from gs (and clean it up to meet mupdf "standards") | 19:02.33 |
| tor8 | and exit with error if the pixel format isn't supported by the file format | 19:02.42 |
| Robin_Watts | tor8: It leaves us free to add other things later; like r4g4b4a4 or anything else. | 19:02.50 |
| tor8 | Robin_Watts: yeah. I'd drop -g as well | 19:03.10 |
| ray_laptop | robin_watts: r4g4b4a4 -- seriously ? | 19:03.17 |
| Robin_Watts | ray_laptop: or c1m1y1k1 as opposed to c8m8y8k8. | 19:03.41 |
| | My point was it's an open enough scheme for future extension. | 19:03.55 |
| tor8 | I'm going to need to probe paulgardiner about how to use signatures tomorrow, in my quest for the best solution to the openssl problem | 19:04.21 |
| | openssl takes twice as long to compile as mupdf + all other third party libraries combined | 19:04.38 |
| Robin_Watts | tor8: I'd be tempted to leave those flags in an deprecate them to avoid breaking peoples existing code (in particular the cluster maybe)? | 19:04.48 |
| ray_laptop | would you have to specify bit depth for each component, or would just a trailing # imply that all were the same, as in cmyk8 == c8m8y8k8 | 19:04.53 |
| tor8 | I do have it compiling using our build system, so cross compilation for android should work | 19:04.59 |
| Robin_Watts | ray_laptop: For now, I propose to ignore the issues of depth. We can worry about that when it rears its head. | 19:05.28 |
| tor8 | Robin_Watts: automatically set the anti-aliasing on monochrome/contone, or do you see value in having it tweakable separately? | 19:06.11 |
| ray_laptop | robin_watts: well, depth for gray is probably sought after (g1 and g8, in particular) | 19:06.34 |
| Robin_Watts | m = g1 | 19:07.33 |
| ray_laptop | tor8: obviously, you don't want AA for depth = 1 | 19:07.35 |
| Robin_Watts | tor8: Yes, I want it tweakable separately. | 19:07.49 |
| | It's been useful for debugging in the past (it's why the option is there :) ) | 19:08.03 |
| | ray_laptop: And we can want AA for depth = 1. | 19:08.29 |
| ray_laptop | also no AA is handy for auto comparison to gs output. | 19:08.33 |
| Robin_Watts | Remember that mupdf always renders in 8bpc, and then dithers down :) | 19:08.39 |
| ray_laptop | robin_watts: really. It is HORRIBLE for character edges (makes them "noisy" looking) | 19:09.11 |
| Robin_Watts | Well, we don't have a concept of rendering text without aa :) | 19:10.37 |
| | unless the chars are REALLY big. | 19:10.49 |
| ray_laptop | robin_watts: that could be a problem | 19:11.10 |
| | robin_watts: try it and have a look. It can make even moderately small text almost illegible. Certainly unaesthetic. | 19:12.23 |
| Robin_Watts | ray_laptop: I understand. How would you suggest we fix it? | 19:13.27 |
| | We could ask freetype to give us un-antialiasing things, but then if they are drawn in colors/shades of grey, you'd be no better off. | 19:13.58 |
| | And if there is blending/transparency going on... | 19:14.12 |
| ray_laptop | robin_watts: I'll have to a look at your code paths. Clearly someplace in the chain knows that the actual target bit depth is 1 | 19:14.25 |
| Robin_Watts | ray_laptop: None of the rendering knows that the target bit depth is 1. | 19:14.47 |
| | We render the whole 8bpc pixmap. | 19:15.04 |
| ray_laptop | robin_watts: I agree that colored/gray text, all bets are off, but for "normal" black text, things are better w/o AA (IMHO) | 19:15.17 |
| Robin_Watts | THEN we convert it to a 1bpp one with some crufty halftoning code. | 19:15.19 |
| ray_laptop | robin_watts: but you _do_ have a way of setting no AA | 19:16.16 |
| Robin_Watts | ray_laptop: We have a way of setting the antialias level for line-art etc. | 19:16.59 |
| ray_laptop | robin_watts: it's just that when rendering text, and when the target is depth 1, use the no AA methods. | 19:17.00 |
| | robin_watts, does 'etc.' include text ? | 19:18.04 |
| Robin_Watts | No. | 19:18.08 |
| | (except for very large glyphs that don't get cached) | 19:18.24 |
| ray_laptop | robin_watts: so requesting no AA still uses AA for text ? | 19:18.26 |
| Robin_Watts | yes. | 19:18.33 |
| ray_laptop | robin_watts: you can still have 8bpp deep in the cache of glyphs, but just drawn without AA | 19:19.08 |
| Robin_Watts | That'd be mad, Ted. | 19:19.51 |
| ray_laptop | and that doesn't defeat using that as a mask for painting a character in a gray shade | 19:19.53 |
| | oh, well. You can just wait and see if a customer ever surfaces that wants 1bpp then fix it :-) | 19:20.44 |
| | robin_watts: or tell them they have to use ghostscript ;-) | 19:21.03 |
| Robin_Watts | yeah, I'll worry more when we have a use case. | 19:21.26 |
| ray_laptop | time for a bit of lunch. bbiaw | 19:21.45 |
| tor8 | Robin_Watts: ray_laptop (for the logs): we actually do test on no-AA to render monochrome text as monochrome with hinting | 19:57.28 |
| vtorri_ | annother question : FZ_META_FORMAT_INFO allows to retrieve the PDF version of the PDF. With XPS, only "XPS" is returned. Is it normal that there is no version ? | 19:57.55 |
| tor8 | fz_render_ft_glyph takes the aa level as an argument | 19:58.03 |
| henrys | Robin_Watts: is this what you want? #if 1 //def PACIFY_VALGRIND | 23:47.32 |
| Robin_Watts | henrys: oh, rats. | 23:47.45 |
| | That was to force the cluster to test it. | 23:47.54 |
| | will fix it, thanks | 23:47.59 |
| henrys | np | 23:48.03 |
| | Forward 1 day (to 2013/05/21)>>> | |
IRC Logs