| | <<<Back 1 day (to 2011/10/31) | 2011/11/01 |
| mvrhel2 | off to trick or treat | 00:23.26 |
| tor8 | Robin_Watts: aaaargh. UIScrollView animations DON'T use the regular animation framework... | 02:15.52 |
| | which means a lot of headaches when tapping page flipping quickly, overwriting the currently playing scroll animation | 02:16.42 |
| | and no sane way to get state out of it either | 02:16.51 |
| arthurf | reads the Human Interface Guidelines while playing with the iPad app | 03:03.18 |
| | tor8: Was thinking maybe something like top->down and bottom->up swipes would be better to unhide the navigation bar and the slider. Top->down would also drop down the Notification Window as well, but at least there would be no tap contention (did the tap mean next page or did the tap mean unhide the bars). | 03:16.00 |
| tor8 | arthurf: right. at the moment I have page flipping if you tap on the left/right 20% of the page area | 03:16.46 |
| | and show/hide the bars in the middle 60% | 03:16.56 |
| | there will also be the slight problem of tapping on hyperlinks once I get that implemented | 03:17.33 |
| | arthurf: do try the latest version in git, I've recently pushed a lot of changes. | 03:23.57 |
| | should make the animations a lot more stable, and added a page indicator and scrubber. | 03:24.16 |
| arthurf | tor8: Yes, I downloaded it just an hour ago or so - looks better | 03:25.31 |
| tor8 | arthurf: my biggest headache now will be getting zooming to work :( | 03:26.23 |
| arthurf | When I first tried the app out - I instinctively wanted to pinch out to zoom in. Figured that would be high on your list. | 03:27.41 |
| tor8 | yeah. it's a nightmare to code though. | 03:28.12 |
| arthurf | Your updates are as of 2 min ago :) I'll go git 'em. | 03:28.42 |
| tor8 | yeah. it's 4.30 and I can't think straight anymore... time to go to bed I think. | 03:38.41 |
| | before I break something :) | 03:38.46 |
| arthurf | I like the page count indicator over the slider and how it spins high and low depending on where the slider button is moved - that's pretty cool. Good night. | 03:39.03 |
| LaoLang_cool_ | How to copy the selection as picture? | 09:55.13 |
| | in mupdf | 09:55.23 |
| Robin_Watts | Helen is desperately trying to find a dep for her concert on the 3rd December :) | 10:01.57 |
| kens | We're talking to the school.... | 10:02.10 |
| Robin_Watts | LaoLang_cool_: It can't be done. | 10:02.14 |
| kens | Helen could fly out on the 4th. Tired but possible ? | 10:02.45 |
| Robin_Watts | No, it should be possible to change. We'll fly out on the Tuesday, and fly back on the sunday evening, I think. | 10:03.42 |
| LaoLang_cool_ | Robin_Watts: oh, thanks for figure it out, I remember that sumatra supports this feature, but I can't find it now, maybe I'm wrong? | 10:09.07 |
| Robin_Watts | LaoLang_cool_: The mupdf viewer doesn't support cut/paste as a bitmap. | 10:09.59 |
| | On windows it can probably be done using Alt-PrintScreen. | 10:10.15 |
| LaoLang_cool_ | Robin_Watts: I got it, don't know if sumartra supports it? I can't find the option in gui... | 10:11.09 |
| | Finally, I realize that a snapshot tool is what I want.. | 10:20.07 |
| Robin_Watts | or just call pdfdraw manually ? | 10:24.39 |
| LaoLang_cool_ | Robin_Watts: I want to copy a region, not a page | 10:26.53 |
| Robin_Watts | Ah. | 10:32.55 |
| | Hmm. | 13:25.47 |
| | I have my new scan converter basically working, but it doesn't play entirely nice with full adjust. | 13:26.09 |
| | s/full/fill/ | 13:26.14 |
| | When I'm winding into the edgebuffers, I can't 'expand' paths by fill adjust because I don't know whether it's a left or a right edge. | 13:27.26 |
| | I can probably apply the fill adjust stuff when I come to play out from the edgebuffers, so I can get fill adjust left/right, but that doesn't help with up/down. | 13:28.35 |
| | I suspect the smart thing to do may be to use the existing scan converter for non-antialiased stuff, and my scan converter for anti-aliased things. | 13:29.26 |
| | (the complexity of antialiased things is higher, hence that's when the new scan converter really pays off, and you don't want to fill adjust when anti-aliasing) | 13:30.00 |
| | My scan converter is not honouring clip paths, it seems. | 14:52.05 |
| kens | That's bad | 14:52.18 |
| Robin_Watts | yes, but it's at least a problem I can understand ;) | 14:57.07 |
| | hehe, pdev -> dev fixed it. | 15:16.38 |
| | http://www.raspberrypi.org/ <- $25 for an ARM based board capable of running linux. | 15:23.27 |
| kens | That's cheap! | 15:23.38 |
| Robin_Watts | I'll buy one when they become available. Seems stupid not to at that price. Could be a nice demo too. | 15:30.39 |
| kens | Ray used to use his Gumstix for that | 15:31.01 |
| henrys | anybody know when marcos gets back? | 15:43.33 |
| kens | I thought he already was :-( | 15:44.12 |
| henrys | maybe we'll have somebody else take a turn next time he's away. | 15:45.58 |
| kens | Second week wasn't half as bad | 15:46.19 |
| henrys | I just had a few issues I think your hours are worse. | 15:48.42 |
| kens | I think I just get unlucky ;-) | 15:48.56 |
| | Hi mvrhel2 | 15:54.24 |
| mvrhel2 | good morning | 15:54.30 |
| Robin_Watts | Morning mvrhel2. | 15:57.59 |
| | henrys, kens: If you do support right, you never get asked to do it again :) | 15:58.31 |
| kens | :-) | 15:58.45 |
| henrys | next time we draw straws | 15:59.21 |
| | 1 of meeting | 16:00.00 |
| Robin_Watts | Oh, right. The hour changed in the UK, so is this now meeting time ? | 16:00.41 |
| henrys | I sent mvrhel2 and alexcher an email about a confusing bug. | 16:00.43 |
| | I believe so 9:00 pacific | 16:01.29 |
| Robin_Watts | fair enough. | 16:01.45 |
| mvrhel2 | henrys: I will look at this bug today | 16:02.17 |
| henrys | mvrhel2:it confused me because somehow it got cast as an x11alpha issue but I'm sure the customer doesn't care about that. | 16:02.50 |
| alexcher | henrys: I have not received anything yet. When it was sent? | 16:02.59 |
| mvrhel2 | ok. I don't know. It was just assigned to me a couple days ago | 16:03.15 |
| henrys | alexcher:I sent it to you late last night. | 16:03.18 |
| mvrhel2 | alexcher passed it to me this weekend | 16:03.38 |
| henrys | mvrhel2:did you get my mail? | 16:03.53 |
| mvrhel2 | yes I did | 16:03.58 |
| henrys | alexcher can you check your spam folder I verified your address is correct on the mail. | 16:05.05 |
| | ? | 16:05.06 |
| | other topics for the meeting? | 16:05.19 |
| kens | I don't think I have anything special. I assume we are still telling HCL to get lost ? THey keep sending me direct mail :-) | 16:05.51 |
| | welcome back marcosw_ | 16:06.00 |
| henrys | marcosw_:are you officially back with all your limbs and stuff... | 16:06.04 |
| kens | And congratulations | 16:06.12 |
| Robin_Watts | Did he not take his limbs with him? | 16:06.28 |
| | indeed, congrats. | 16:06.37 |
| marcosw_ | henrys, et.al.: yes, I'm back. | 16:06.41 |
| henrys | kens:right they are persistent aren't they? | 16:07.13 |
| kens | That's one way to put it. | 16:07.34 |
| | They sent me a docx file today.... | 16:07.40 |
| chrisl | kens: one for the kill file..... | 16:08.12 |
| kens | Yep :-) | 16:08.28 |
| henrys | chrisl:how goes the type 1 ft research? | 16:08.36 |
| chrisl | henrys: I'm part way through implementing the API to get the Type 1 data out of freetype. | 16:09.02 |
| | Werner has given tacit approval for the additional functionality we need | 16:09.32 |
| henrys | it will be nice to get that in. | 16:09.40 |
| chrisl | The downside is we won't get the entire Type 1 dictionary out, but clearly (as other PDF consumers use Freetype for these fonts) we don't actually need that | 16:10.31 |
| henrys | tor8:any refinement to the iOS schedule, scott nags me about that everytime I talk to him | 16:10.31 |
| | ? | 16:10.44 |
| tor8 | henrys: it's on track | 16:11.00 |
| Robin_Watts | I have ideas about improving the speed of the bitmap scaling further. | 16:11.44 |
| tor8 | henrys: it's still missing three features; I'm hoping to get them done by this week | 16:11.51 |
| henrys | Robin_Watts:the python folks have infuriated me I'm redoing the asm and dis in C... | 16:12.10 |
| tor8 | remembering the location where you last were in a document, hyperlinks, and XPS support | 16:12.12 |
| | search will have to wait for a later update, or scott will get too antsy :) | 16:12.26 |
| henrys | hmm search is a pretty basic need. | 16:13.08 |
| tor8 | henrys: then expect to tack on another week (or two, if things turn ugly) on the schedule | 16:13.32 |
| henrys | if it is 2 week more I'd rather have it in. | 16:13.35 |
| tor8 | alright. | 16:13.43 |
| henrys | so give me your best date given that and I'll pass it on. | 16:14.02 |
| tor8 | henrys: release candidate in three weeks, plus whatever apple needs to approve | 16:14.43 |
| henrys | fair enough thanks | 16:14.55 |
| | I guess ray_laptop is out anybody else have something for the meeting? | 16:15.20 |
| tor8 | henrys: the ios work is on my casper git, if you want to give it a spin | 16:15.26 |
| | it's already miles better than the old demo | 16:15.31 |
| alexcher | henrys: My confused messages about the bug 692557 are related to rge choice of or x11alpha devices in different versions. In short, x11 works, x11alpha doesn't show an image. The PS error they report is a new issue, which I didn't analyze yet. | 16:16.10 |
| ray_laptop | I don't know why, but I can't get chatzilla to connect, so using webchat :-( | 16:16.18 |
| henrys | tor8:you mean in the xcode simulator? | 16:16.18 |
| tor8 | henrys: or on your ipad/iphone if you have one | 16:16.43 |
| | I went out and bought an iPad 2 | 16:16.48 |
| mvrhel2 | I am confused with what it is I am supposed to do then with 692557 | 16:16.51 |
| | what is the customer issue? | 16:17.02 |
| Robin_Watts | alexcher: What is the status of the project to remove C++ reserved words from the gs source? | 16:17.06 |
| ray_laptop | sorry I'm late. I was just about to sign on when Scott and Miles called and wanted to discuss our visit to company C tomorrow -- then cust 532 called. | 16:17.07 |
| mvrhel2 | that should be the focus | 16:17.08 |
| henrys | Robin_Watts:you'd think we'd change times the same weekend, I thought we did. | 16:17.19 |
| | ray_laptop:np] | 16:17.26 |
| Robin_Watts | henrys: So did I, hence my surprise that the time was different. | 16:17.39 |
| henrys | mvrhel2:hang on I'll get it. | 16:18.09 |
| alexcher | Robin_Watts: It's abandoned. We have to change many macros because of the stricter type usage. In C++ we have to pass a type and a variable as 2 parameters, instead of MACRO((type)foo). | 16:19.55 |
| henrys | I see the bug was never filled out properly. marcosw_ can you fix 692557 with the original command line and test file? | 16:20.20 |
| Robin_Watts | alexcher: That sounds like a different project. | 16:20.49 |
| | That sounds like "make it possible to compile gs as a C++ beast". | 16:21.06 |
| henrys | marcosw_:well the test file is there but you never added the command line from the customer's email. | 16:21.07 |
| | mvrhel2:one of us will update the bug. | 16:21.29 |
| Robin_Watts | I just want "avoid using C++ reserved words in gs" as that's enough to confuse MSVC etc when debugging. | 16:21.39 |
| | alexcher: So no objections to anyone else doing piecemeal renamings as we encounter problems ? | 16:22.11 |
| mvrhel2 | henrys: ok thanks | 16:22.14 |
| | Robin_Watts: I would welcome that | 16:22.33 |
| henrys | ray_laptop:did you have anything for the meeting? | 16:22.48 |
| marcosw_ | henrys: I didn't enter 692557 but will look for the customer's email for the command line | 16:22.54 |
| henrys | I was looking at your response of Sep 29 to the customer which says we opened a bug... but obviously you don't even have a comment in the bug. | 16:24.08 |
| ray_laptop | Just wanted to know if mvrhel2 or Robin_Watts (or anyone else) has any things they'd like brought up with Company C (why we are better than Adobe PDF + Monotype PCL) | 16:25.13 |
| Robin_Watts | ray_laptop: That sounds like sales stuff. | 16:25.43 |
| henrys | I did have one other thing for Robin_Watts I'd prefer not have anyone automatically rewriting white space. How do others feel about that? | 16:25.47 |
| ray_laptop | Primary point I was going to bring up was single graphics library | 16:25.50 |
| Robin_Watts | henrys: I don't believe I automatically rewrite whitespace. | 16:26.06 |
| kens | smaller binary, smaller memory footprint | 16:26.15 |
| ray_laptop | changing white space make 'blame' pretty useless | 16:26.25 |
| Robin_Watts | (That is, we've stripped trailing spaces out of the source tree already, I believe, and that's all the automatic rewriting I do) | 16:26.45 |
| | *Subconcious* white space changing, well, I might plead guilty to that :) | 16:27.06 |
| henrys | ray_laptop:we don't know anything about their product - obviously price is an issue that needs to be straightened out... | 16:27.16 |
| ray_laptop | henrys: Miles and Scott will handle that part -- I was just going to bring up tech issues. | 16:27.48 |
| | does Adobe or Monotype have (embedded) XPS ? | 16:28.07 |
| ray_laptop | didn't think they did | 16:28.21 |
| mvrhel2 | ray_laptop: I think Monotype may have XPS http://www.monotypeimaging.com/productsservices/driverbenefits.aspx | 16:28.58 |
| | not sure about embedded side though | 16:29.24 |
| | that is a driver | 16:29.26 |
| Robin_Watts | ray_laptop: The state of play was that I had a first port working, but not fully integrated with their print stack due to problems with their stack. | 16:29.27 |
| | It was enough to run some test files and get timings. | 16:29.45 |
| | I gave a binary to Mq to play with, and that was the last I heard. | 16:29.58 |
| marcosw_ | mvrhel2: could you have a look at http://bugs.ghostscript.com/show_bug.cgi?id=692639 when you get a chance? It's causes issues with a bunch of the regression files. | 16:30.12 |
| Robin_Watts | No real board specific performance tuning had been done. | 16:30.28 |
| mvrhel2 | marcosw_: yes I will | 16:30.30 |
| | look into that today | 16:30.37 |
| henrys | Robin_Watts:we haven't stripped trailing space out of pcl and you recently made a change to pcparse.c I think I can look but I'd rather we just make change intentional and not automatic as a policy. | 16:30.42 |
| marcosw_ | thx | 16:30.44 |
| ray_laptop | mvrhel2: that looks like it is discussing their Windows/Mac printer driver -- not a RIP | 16:31.12 |
| mvrhel2 | this is what we are competing against http://ir.monotypeimaging.com/releasedetail.cfm?ReleaseID=489819 | 16:31.14 |
| Robin_Watts | henrys: OK. I'll try and avoid it in future. | 16:31.16 |
| mvrhel2 | ray_laptop: yes | 16:31.23 |
| henrys | well we are 5 minutes over meeting finish time. | 16:36.09 |
| mvrhel2 | ray_laptop: having the single graphics library and a common color architecture between the solutions would seem to be the biggest plus. Although they are going to do their own color tables for the final conversion, they do need to have consistency in getting the different source colors to the proper input space for their tables | 16:36.19 |
| ray_laptop | Their "release" announcement is just marketing hype, so it's hard to tell what's real | 16:37.06 |
| mvrhel2 | ray_laptop : yes. | 16:37.30 |
| ray_laptop | The big advantage they have is that they have a Windows driver _and_ the fonts so they can do 'bundle' pricing, but I really don't understand how they have an advantage when using Adobe PS | 16:38.38 |
| mvrhel2 | ray_laptop: right | 16:38.49 |
| henrys | ray_laptop, mvrhel2:everything in the statement seems quite believable to me. What would you question as unreal? | 16:39.00 |
| mvrhel2 | I am just agreeing that it is a marketing statement | 16:39.28 |
| | They must have the various PDL renderers I would think | 16:39.48 |
| | when combined | 16:39.53 |
| henrys | I would hope you would bring up our pcl has been in the field for a quite a while. | 16:39.57 |
| | having a new pcl interpreter unexposed to legacy files is usually not a good thing ;-) | 16:40.49 |
| ray_laptop | henrys: they imply that their CMM is used for all PDL's but Adobe's doesn't have CMM hooks (or at least didn't used to) -- unless they always render to RGB and do color conversion on the back end | 16:41.06 |
| | henrys: yes, the fact that our PCL has been through "real world" printer QA and and has been shipping for, what? almost 10 years ? | 16:42.09 |
| henrys | I think adobe does have that now. | 16:42.35 |
| mvrhel2 | ray_laptop: that is a good point. It is easy for us to hook into whatever CMM company C would want to use. They do not have their own CMM though and I would suspect they would be fine with lcms. It might be worth mentioning that I would be available to help them with color/halftone issues as I developed all the tables and screens in their older stuff | 16:42.38 |
| ray_laptop | but being in IBM, Oce and having gone through the QA with (not real) cust 951 counts | 16:43.00 |
| | mvrhel2: OK. Good point, thanks | 16:43.26 |
| | I haven't seen anything from Adobe about redesigning their PS -- their PDF Print Engine, yes, but I thought they just sort of punted on PS | 16:44.39 |
| henrys | it is a difficult situation though - if the pricing isn't agressive we don't have a chance, I think that is clear to Miles and Scott. | 16:45.22 |
| ray_laptop | I can see if Scott can query Hennes about that | 16:45.26 |
| mvrhel2 | you do have to realize that they are competing against Zoran | 16:46.22 |
| | in the hardware market | 16:46.29 |
| | so they (company C) are really looking to have the cheapest solution possible since Zoran has the full bundle | 16:46.59 |
| Robin_Watts | mvrhel2: Well, with us, they would have the full bundle too, right? | 16:47.22 |
| mvrhel2 | yes | 16:47.31 |
| ray_laptop | mvrhel2: RIght -- competing against Zoran. | 16:47.41 |
| | maybe they really want Adobe as a marketing advantage over Zoran (with clone PS). With us they are clone the whole way | 16:48.23 |
| mvrhel2 | my point is that company C is at a disadvantage as Zoran has it all internally | 16:48.27 |
| | that is possible. | 16:48.49 |
| | I don't see though why they could not offer both solutions as an option | 16:49.06 |
| | then | 16:49.07 |
| | with different costs | 16:49.12 |
| kens | support headache | 16:49.45 |
| ray_laptop | mvrhel2: I think Miles and Scott will push that | 16:49.49 |
| henrys | exactly. | 16:49.50 |
| mvrhel2 | hehe they need to get some customers before they worry about the support headaches | 16:50.21 |
| henrys | I'd be very surprised if they did that. It's a lot of work to port and maintain these architectures. | 16:50.35 |
| mvrhel2 | that is true. but if they offer their customers more options. price is usually the number one deal killer in these things | 16:51.16 |
| henrys | they have to make an initial investment to port and test - | 16:51.19 |
| mvrhel2 | MQ had indicated to me at lunch that it all came down to price in the end | 16:52.05 |
| ray_laptop | henrys: the support is usually between the end customer (printer mfg.) and the s/w vendor -- they (company C) is _not_ going to have the ability to support directly. | 16:52.10 |
| mvrhel2 | thats what I would think | 16:52.25 |
| | they would just pass it along | 16:52.30 |
| ray_laptop | and with Adobe + Monotype, the end customer is dealing with two people (unless Monotype is now a co-developer) | 16:52.45 |
| henrys | certainly that is not what happened with teco - they invested hugely to get our stuff up and running. | 16:53.02 |
| ray_laptop | teco spent a lot of time on QA (and putting us through the wringer), but I don't think they spent all that much effort in the port | 16:54.07 |
| | although they claimed to have re-written 30% of our stuff, I seriously question that | 16:55.14 |
| henrys | I am much less optimistic - I see minimally a 3 man month engineering effort associated with going with one company and six for 2. Just QA is going to be a significant part of that. | 16:56.45 |
| | but no point in arguing about it. | 16:57.20 |
| ray_laptop | henrys: agreed | 16:57.29 |
| mvrhel2 | henrys: Now I am really confused by bug 692557 | 16:58.10 |
| | I ran it with the command line and it looks ok to me | 16:58.19 |
| henrys | I guess Adobe's poor revenues have driven them back to the printer market. | 16:58.49 |
| | mvrhel2:don't know that was the customer's command line which he said was broken, maybe specific to a release? | 17:00.54 |
| ray_laptop | mvrhel2: do you have any thoughts (and can you reproduce my results) with my last comment on bug 692518 ? | 17:01.13 |
| | bug 692618 | 17:01.25 |
| mvrhel2 | oh that sounds weird | 17:03.17 |
| henrys | mvrhel2:best to assign it back to marcosw_ so he tends to it. | 17:03.36 |
| mvrhel2 | ok | 17:03.40 |
| henrys | marcosw_:can you follow up on that? I implied to the customer we'd get back to them soon. | 17:04.55 |
| marcosw_ | sorry, I wasn't paying attention. Is this bug 692618? | 17:05.31 |
| mvrhel2 | bug 692557 | 17:05.42 |
| ray_laptop | I'm getting my tires changed, and my laptop battery is dying, so I'm going to sign off now. | 17:09.15 |
| | bye, all | 17:09.19 |
| mvrhel2 | ray_laptop | 17:09.20 |
| | I will call you | 17:09.24 |
| ray_laptop | mvrhel2: yes ? | 17:09.25 |
| | OK. that'll be better. | 17:09.34 |
| | (so my battery doesn't totally die) | 17:09.45 |
| cwmien | hi | 17:13.48 |
| kens | hello | 17:14.53 |
| ghostbot | hola | 17:14.53 |
| kens | ghostbot was slow.... | 17:15.01 |
| cwmien | i find this channel from the mupdf official site. is right channel to discuss about mupdf? | 17:15.50 |
| Robin_Watts | cwmien: Yes. | 17:16.16 |
| | We should get ray_laptop to amend the topic to say "Ghostscript (and MuPDF) development and discussion" | 17:16.53 |
| cwmien | oh, i find the mupdf first on the internet. And I use it and love it immediately . it is so perfect for me. So fast and so slim. And I have a HP touchpad runing webOS system and the pdf reader on it is just shit. So is it any chance to port the mupdf to the webos? | 17:22.53 |
| kens | Should be possible. | 17:23.23 |
| Robin_Watts | cwmien: It's certainly possible. it's not on our roadmap at the moment though. | 17:23.55 |
| | But if you want to have a go, please feel free. We are here if you have questions etc. | 17:24.27 |
| cwmien | thanks. | 17:27.33 |
| kens | Heading off for the night, see you all tomorrow. | 17:28.57 |
| cwmien | And the webOS is just based on linux. If I compile the source on the webos. which part maybe I need to change? | 17:29.56 |
| Robin_Watts | I don't know how webos gets data to the screen. | 17:30.24 |
| | The example mupdf viewers etc are a very thin layer wrapped around the mupdf core. | 17:30.49 |
| | It's that layer you need to port. | 17:31.07 |
| cwmien | ok, I get it. And I will read the source first and find how to start the job. Thank u for your help | 17:33.24 |
| Robin_Watts | good luck. | 17:37.58 |
| | henrys: I have my scanline renderer working, I think (just doing a cluster push now). | 17:54.29 |
| | It's MUCH faster in the pathological cases (~2 seconds rather than 15 mins for one bug). | 17:55.00 |
| | but I can't see a way of making it do fill adjust properly, at least in the vertical direction. | 17:55.50 |
| | So I'm tempted to hook my scanline renderer up so that it only gets called when antialiasing is enabled (or when fill_adjust is 0). | 17:57.00 |
| | What do you think ? | 17:57.03 |
| henrys | I think that's the right thing to do. | 17:58.12 |
| | what is the issue with fill adjust though? | 17:58.23 |
| Robin_Watts | It's down to the way my algorithm works. | 17:59.15 |
| henrys | we do have some wiggle room with that as it is a rendering (device specific) parameter. | 17:59.16 |
| Robin_Watts | I make a table that lists, for every scanline in the band we're rendering, all the x coordinates at which the path cuts that line. | 18:00.29 |
| | (together with whether it's an 'up' or a 'down' cut) | 18:01.25 |
| | Then for each scanline, I can sort the intersections on x, filter them (according to the winding rule in use) and fill in the blanks. | 18:02.18 |
| | Make sense? | 18:04.01 |
| henrys | so far | 18:04.37 |
| Robin_Watts | I can't apply fill adjust while creating that table, because I have no idea what side of the shape is 'in' or 'out'. | 18:04.57 |
| | So the table has to be made with the exact edge positions of the shape. | 18:05.36 |
| | When I come to fill the table though, I can expand my points to left and right and get the fill adjust on x as we'd want. | 18:06.28 |
| | I can't do that on y though. | 18:06.49 |
| | The traditional gs scan converter scan converts in trapezoids, where the height of the trapezoids are the 'natural' height. | 18:08.12 |
| | My scan converter converts to scanlines, hence it inherently quantises the data in the y direction, which means we lose the ability to fill adjust it on y. | 18:09.22 |
| henrys | so if fill adjust is on we use trapezoids I suppose, I wonder though if we can do something to fudge this earlier in the pipeline but nothing comes to mind. | 18:10.55 |
| | oh wait fill adjust, I was thinking strokeadjust christ that mess. | 18:12.50 |
| Robin_Watts | I seem to be prone to losing horizontal lines too. It's the same essential issue. | 18:13.42 |
| henrys | fill adjust is always on for vectors except for some fonts... | 18:13.48 |
| chrisl | It should be off for all fonts, IIRC...... | 18:14.27 |
| Robin_Watts | I *think* fill adjust should be turned off when anti-aliasing is on. | 18:14.40 |
| | fill adjust is essentially intended to stop dropouts. | 18:14.53 |
| | When AA is on, dropouts should be taken care of by that. | 18:15.06 |
| | So maybe we should only use my scanline converter when AA is on. | 18:15.23 |
| henrys | I think that is reasonable, was the performance bug an AA issue? | 18:15.26 |
| Robin_Watts | Yes. | 18:15.32 |
| chrisl | You might also want fill adjust with "write white" devices - but whether they would be used with AA, I don't know | 18:16.04 |
| henrys | but I don't see how we could use the scan converter if AA is off for anything useful. As you know fill adjust is our hacked up way of doing touched (not center of pixel) rendering - we can't just change the rendering | 18:17.22 |
| Robin_Watts | Essentially each scanline entry in the table stores enough information to tell us the X regions of a scanline that have the centre of a pixel touched. | 18:19.22 |
| | If I double the number of scanlines in the table, can I hold enough information to tell me if 'any part of a pixel' is touched? | 18:20.07 |
| | Need to think on that. | 18:20.13 |
| chrisl | There are fonts that get a similar effect by filling the outline, moving it a partial pixel "down" and stroking the same outline | 18:21.49 |
| Robin_Watts | chrisl: Yes, I had considered doing exactly that :) | 18:22.13 |
| chrisl | Yeh, it's a bit hacky though - I looked at doing that for PCL on Jaws way back when...... | 18:22.44 |
| Robin_Watts | That works for non-zero filled things, but even-odd filled things are harder. | 18:22.47 |
| | henrys: I saw this and thought of you, btw... http://www.maplin.co.uk/digital-usb-microscope-with-2.4-inch-lcd-screen-and-190x-magnification-536019 | 18:24.09 |
| henrys | chrisl, Robin_Watts:does the stroke/fill color work with fonts - stroked fonts vs. normal fonts in PDF? | 18:24.27 |
| | Robin_Watts:that looks nicer than mine. | 18:25.12 |
| Robin_Watts | That's the different stroked/filled rendering modes, right? | 18:25.15 |
| henrys | right, yes | 18:25.22 |
| | I guess there are 2 questions does PDF do it and does your code do it? | 18:25.46 |
| Robin_Watts | I believe it should, but I'm fuzzy on the details. | 18:25.48 |
| | henrys: Well, the pdf interpreter must set it up right, because kens has it going through pdfwrite. | 18:26.14 |
| henrys | I might be using it in pcl. | 18:26.57 |
| | gs_swapcolors that is. | 18:27.04 |
| chrisl | henrys: you mean a glyph outlines that are stroked, or PaintType 2 fonts? | 18:27.25 |
| Robin_Watts | If you're doing gs_swapcolors, then you're golden, I think. | 18:27.29 |
| henrys | chrisl:yes I would think stroked fonts would use the stroking color, no? | 18:28.11 |
| chrisl | Yes, I would think so, but I haven't tested that. I did test whatever tr mode in PDF is stroked, though | 18:28.48 |
| Robin_Watts | Urm... What's the difference between 'stroked fonts' and 'fonts that use stroking because of Tr' ? | 18:29.39 |
| chrisl | In the output, nothing. But the latter is handled entirely withing the PDF interpreter logic, whereas the former is handled, at least partly in the font machinery | 18:31.16 |
| | s/withing/within | 18:31.27 |
| Robin_Watts | So what are 'stroked fonts'? You mean type 3 fonts that happen to have stroke commands within the glyph streams? | 18:31.58 |
| chrisl | No, Type 1 (at least) has a PaintType setting, and that means the glyph is stroked rather than filled by the renderer | 18:32.58 |
| henrys | as does truetype | 18:34.38 |
| Robin_Watts | Ah, right. | 18:34.41 |
| | Well, the PDF interpreters 'color setting' logic always sets stroke color and glyph color with the appropriate swapcolors things. | 18:35.15 |
| | so it should always call the underlying font code with the correct fill/stroke colors, and I'd hope we should be OK. | 18:35.48 |
| | I may have an idea about how to make the scanline converter work right. | 18:36.16 |
| chrisl | Robin_Watts: the problem is, that for stroked fonts to work, the PDF interpreter needs to check if the current font is a stroked font before rendering, and I'm not sure if it does that. | 18:36.24 |
| Robin_Watts | Why does it need to check? | 18:36.43 |
| | As long as it's set the stroke color correctly, who cares? | 18:37.04 |
| chrisl | Well, only by knowing if the font should be stroked or filled would it know whether to set the stroke or fill color | 18:37.15 |
| Robin_Watts | We have 2 color entries in the color state, a stroke one, and a fill one. | 18:37.50 |
| | I guess it might 'helpfully' do a swap when we don't expect it to to make the stroke one current. | 18:38.39 |
| chrisl | So we don't need to make the appropriate one "active" before a drawing operation? | 18:38.40 |
| Robin_Watts | Yes, currently we do. | 18:38.51 |
| | so yes, I see what needs checking. | 18:39.21 |
| chrisl | So we'd need the stroke color to be made active before rendering a stroked glyph, wouldn't we? | 18:39.25 |
| | Oh, good. | 18:39.38 |
| Robin_Watts | chrisl: Well, whether we do or not depends on what convention we want to apply. | 18:39.50 |
| chrisl | You lost me, there...... | 18:40.10 |
| Robin_Watts | We could apply the convention that the PDF interpreter will ensure that both stroke and fill colors are correct on every call to the underlying font stuff, and the underlying font stuff could select based on whether it's a stroked font or not. | 18:40.43 |
| | that would keep the PDF interpreter simpler, and would mean that the font manager could cope with (hypothetical) fonts that both stroke and fill. | 18:41.30 |
| chrisl | Oh, I see. I'm not really bothered either way - I don't *think* the font code does that at the moment. I can't remember whether the PDF interpreter checks it. | 18:42.17 |
| Robin_Watts | but I guess that would be at odds to what postscript using those fonts would do. | 18:42.20 |
| chrisl | To be honest, PaintType 2 fonts are so rare, I'm not going to lose much sleep over it...... | 18:42.58 |
| henrys | indeed not an important issue at all. | 18:43.41 |
| | a bit more common with cjk fonts though. | 18:44.07 |
| Robin_Watts | At the moment, for each scanline, I store the set of x coordinates at which the edge crosses the vertical midpoint of the scanline. | 18:44.08 |
| | If instead I move to storing the set of xcoordinates at which the edge crosses into the bottom of the scanline, then I *think* I can get what I need for the fill_adjust = 0.5 case by combining the scanlines data with the scanline above it. | 18:45.22 |
| chrisl | henrys: if it's a source of concern (stroked fonts) I can easily hack up a test file later in the week. | 18:46.41 |
| Robin_Watts | I can generate a set of intervals to fill from each of the scanlines data, and then union it. | 18:46.59 |
| chrisl | Oh, cr*p, I'm late - have to go. Nite folks! | 18:49.18 |
| Robin_Watts | Bah. Even that's not enough to catch the 'thin horizontal stroke' case :( | 18:55.16 |
| ray_laptop | Robin_Watts: I want to try loading the mupdf app on my android tablet. Can I download it from somewhere ? | 19:27.33 |
| | tor8: same question to you | 19:27.45 |
| | I had tried an early app on an earlier tablet and it wouldn't run, but I haven't tried it on the newest one I have | 19:28.31 |
| tor8 | ray: Robin_Watts is better equipped to ask, he may have an app archive lying around | 19:28.50 |
| ray_laptop | I probably missed Robin_Watts :-( | 19:29.01 |
| tor8 | ray: if you have the android ndk and sdk installed, you can compile from source | 19:29.03 |
| Robin_Watts | I'm here. | 19:29.06 |
| | Just a tick. | 19:29.16 |
| ray_laptop | I don't have them installed. Do they run on Windoze ? | 19:29.27 |
| Robin_Watts | ray_laptop: Yes. | 19:29.35 |
| | see android/ReadMe.txt for step by step instructions. | 19:29.55 |
| ray_laptop | maybe I'll give it a whirl then (building it) | 19:30.00 |
| | Robin_Watts: thanks | 19:30.06 |
| Robin_Watts | I'll sort out an upload. | 19:30.10 |
| ray_laptop | Robin_Watts: that would save me a bit of work (but I might try it anyway). mvrhel2 pointed out that we should pitch mupdf to Company C tomorrow | 19:30.58 |
| Robin_Watts | The version I have is in timing mode. rebuilding now. | 19:32.15 |
| | It's VERY rudimentary. | 19:32.30 |
| ray_laptop | Robin_Watts: that's OK for a demo. It may help open the discussions | 19:34.12 |
| | (if it runs on my tablet). I'm pretty sure it's 2.2 in case that matters, but I don't have it with me at the moment | 19:34.49 |
| Robin_Watts | ray_laptop: http://ghostscript.com/~robin/MuPDF-debug.apk | 19:35.12 |
| | oops, still uploading. | 19:35.20 |
| ray_laptop | Robin_Watts: thanks a bunch. | 19:35.22 |
| Robin_Watts | You'll need to put a test pdf in /sdcard/Download/test.pdf | 19:35.38 |
| ray_laptop | I assume I just download from my tablet, right | 19:35.58 |
| Robin_Watts | I have no idea :( | 19:36.10 |
| | but maybe, yes. | 19:36.15 |
| ray_laptop | Robin_Watts: OK. | 19:37.08 |
| Robin_Watts | still uploading... | 19:37.22 |
| | ok, that's it. | 19:37.40 |
| | Forward 1 day (to 2011/11/02)>>> | |
IRC Logs