| | <<<Back 1 day (to 2014/02/17) | 2014/02/18 |
| Robin_Watts | marcosw_: Hi | 00:11.47 |
| marcosw_ | Robin_Watts: hello | 00:12.04 |
| Robin_Watts | marcosw_: Could you kick off another pdf vs bmp comparison please? | 00:12.21 |
| marcosw_ | you're working late :-) | 00:12.26 |
| Robin_Watts | Again, don't do bugs, just put the PDFs up for me to look at. | 00:12.34 |
| | marcosw_: Nah. I'm just on my way to bed. | 00:12.43 |
| marcosw_ | okay, I'll start the code, it will be done in the morning, your time. | 00:13.03 |
| Robin_Watts | Hopefully I've sorted the justification stuff, so the text should be a better match now. | 00:13.14 |
| | Thanks. | 00:13.16 |
| marcosw_ | Robin_Watts: the pdf vs bmp comparison is finished and the files are uploaded. | 01:16.42 |
| chrisl | tor8: small mupdf commit for you: http://git.ghostscript.com/?p=user/chrisl/mupdf.git;a=commitdiff;h=a1992d34 | 09:44.49 |
| tor8 | chrisl: pushed. | 10:20.04 |
| chrisl | tor8: thanks | 10:20.36 |
| tor8 | chrisl: what did you do to run into this? or is it a bug report? | 10:23.09 |
| chrisl | tor8: looking at mooscript - the names clashed with the GS ones. I made a similar change for GS | 10:24.42 |
| tor8 | ah! | 10:24.50 |
| | how is mooscript, has it bitrotted a lot? | 10:25.05 |
| chrisl | Yes, practically every fitz device method has changed..... | 10:25.29 |
| tor8 | Hm, yes, I guess the mooscript code is from before Robin changed the calling conventions to pass matrices by const pointer rather than by value | 10:26.55 |
| Robin_Watts | chrisl: ah, yes. sorry. | 10:27.26 |
| chrisl | Such sh*t happens. Hopefully, I'll have something worth talking about by the staff meeting. | 10:28.31 |
| | tor8: When are you planning to freeze the mupdf/fitz APIs, so they are start to explode in size like the GS ones ;-) | 10:33.42 |
| tor8 | chrisl: When hell freezes over ;) So far I haven't felt too many customer complaints about our liquid API... | 10:35.25 |
| | though sometimes I fear for zenikos sanity... | 10:35.36 |
| chrisl | I just can't help but feel that there *must* be some workable point between the GS *never* change, and the mupdf change between every release...... | 10:36.36 |
| tor8 | chrisl: yeah. the problem is that we keep adding features to mupdf that sometimes mean we want to change/clean up some bits of the API | 10:37.25 |
| | chrisl: though I think you hit the second largest API change in mupdf's history, we do try to keep the API changes minor when possible | 10:38.11 |
| | the biggest one being the huge renaming of every single function for the underscore_peppered_naming_convention | 10:38.48 |
| | and the second biggest one, changing all the fz_point, fz_rect and fz_matrix calls to be by const pointer rather than value | 10:39.07 |
| chrisl | tor8: and the mirror of that is features have been added to the GS device API, but it's not had a proper clean up in 20+ years. I think the clarity of the mupdf API speaks to the wisdom of those tidy ups. | 10:39.27 |
| tor8 | yeah. sometimes it's really hard to know which of the fifteen semi-deprecated gs functions actually do what they advertise... and which one should be used. | 10:40.34 |
| chrisl | tor8: It's just my least favourite hobby horse - the GS device API. I rather feel that the small effort to track the mupdf API changes is worth the (probably) man-years it will save us in the long term | 10:41.37 |
| paulgardiner | Robin_Watts: filename correction is on paul/ghostdocs-demo | 11:13.43 |
| | Decided to go with passing the name between intents in the end. | 11:15.15 |
| Robin_Watts | paulgardiner: Ok, ta. | 11:16.32 |
| Xavier | hi | 14:30.58 |
| | i would like to have some informations about ghostscript | 14:31.25 |
| | someone can help me? | 14:31.29 |
| Robin_Watts | Xavier: Ask away. | 14:32.47 |
| henrys | Robin_Watts: you scared him off | 14:33.18 |
| Robin_Watts | result! | 14:33.43 |
| | I got annoyed with the epage code yesterday, and made a visual studio solution for it, in the same way the ghostscript solution works. | 14:42.49 |
| | VS lists all the files, but calls the FBS to do the build. | 14:43.14 |
| | I tweaked the FBS to make .sbr files this morning, and hacked a bscmake into the FBS invocation line in the solution, and I now have proper searching and 'goto definition' and autocompletion etc working. | 14:44.18 |
| henrys | Robin_Watts: have you spoken to Bipartate - Alex about FBS? Could we pay them to replace it with something sane? | 14:44.22 |
| Robin_Watts | We'd need to figure out what that 'sane' thing is. | 14:44.46 |
| henrys | Robin_Watts: well yes | 14:45.04 |
| | and arguable there are no sane build systems, at least for C | 14:45.44 |
| Robin_Watts | If we can establish exactly what targets we need to keep building are (for what platforms), then we can start to get a shape for what we need. | 14:45.51 |
| | The FBS (however annoying it may be) is a sensible solution for the wide range of options/targets/platforms/configurations Picsel were targetting (for certain definitions of sensible at least) | 14:46.54 |
| | but, yes, I'm sure they could help us. | 14:51.02 |
| | They have the experience of maintaining the FBS over the past few years, so they know where the bodies are buried. | 14:51.34 |
| beatmeister | Hello | 14:52.37 |
| | Can you help me please | 14:53.30 |
| Robin_Watts | beatmeister: Third door on the left. | 14:54.08 |
| beatmeister | How can i find the ghostscript installed files on unix | 14:54.10 |
| tor8 | Robin_Watts: henrys: as horrible as it is, cmake is becoming more and more common | 14:54.15 |
| paulgardiner | henr Yeah, I'm not sure about replacing the FBS now we plan to maintain the app. Replacing it for | 14:54.20 |
| beatmeister | Im on hp ux | 14:54.43 |
| Robin_Watts | beatmeister: Are you building from vanilla gs sources? Or are you building from a package from your distro? | 14:55.27 |
| henrys | flying in the rockies... we seem to get one of these every couple years:http://www.denverpost.com/news/ci_25165449/turbulence-injures-flight-attendant-denver-billings-route?source=rss and most flights you get a rattling about. | 14:55.29 |
| | tor8: yeah I was going to say that. | 14:55.41 |
| paulgardiner | Try again. henrys: I'm not sure about replacing the FBS now we plan to maintian the app. Replacing it to build the smallish part of epage we were previously intending to pull out makes a lot of sense, but when building the entire app, the FBS is complicated partly because it does a complcated cjob. | 14:56.00 |
| Robin_Watts | I have no experience of CMake. | 14:56.10 |
| henrys | tor8: what about ios and android? | 14:56.23 |
| beatmeister | Wich is the directory of the ghostscript installation on unix | 14:56.53 |
| | Please | 14:56.56 |
| Robin_Watts | beatmeister: I asked you a question. Without the answer to that we cannot answer you | 14:57.27 |
| beatmeister | O sorry i didnt see it | 14:58.20 |
| tor8 | henrys: yeah, probably not going to be useful there though... | 14:58.41 |
| | henrys: so, any news on the URW cyrillic front? | 14:58.51 |
| henrys | tor8: no actually the ball is in my court for that. I'll followup today. | 14:59.39 |
| beatmeister | Its not from the distro | 15:00.08 |
| henrys | paulgardiner: all build systems suck there is some value to having something everyone else is suffering with. | 15:00.18 |
| paulgardiner | so move to something more standard? | 15:01.07 |
| Robin_Watts | beatmeister: So you got the sources from downloads.ghostscript.com or somewhere? | 15:01.44 |
| beatmesiter2 | But actually what i want to know is wich .so files does ghostscript install | 15:02.12 |
| Robin_Watts | beatmesiter2: I don't know the answer, but chrisl probably does. He's away at the moment, but should be back soon. | 15:02.49 |
| henrys | paulgardiner: right | 15:03.26 |
| Robin_Watts | beatmesiter2: He'll probably want to know exactly what build command you're using. | 15:03.34 |
| tor8 | beatmeister: beatmeister2: ldd $(which gs) | 15:04.31 |
| paulgardiner | my fear with replacing the FBS for building the entire app is that it might be a huge job, and we might never quite get the replacement to catch up with all the options the FBS handles. | 15:04.31 |
| beatmesiter2 | Mmm ok thank you | 15:05.17 |
| Robin_Watts | I have this (possibly stupidly optimistic) hope that we might only need to support 1 target for a small set of OS now. | 15:07.29 |
| | (windows/windows phone/android/ios/linux ?) | 15:07.56 |
| | and so moving to vanilla makefiles might be possible. | 15:08.09 |
| | or even gnu makefiles. | 15:08.18 |
| | gnu make is available for windows I think, but we avoid relying on it for gs. | 15:08.45 |
| | In fact, msys git comes with gnu make, so as we are using git, we all have it. | 15:09.30 |
| henrys | hi ray_laptop_ | 15:11.15 |
| | Robin_Watts: I think that set is quite reasonable I don't know about the OEM's though. | 15:12.50 |
| Robin_Watts | henrys: Indeed, we need to look over the OEM agreements to be sure. | 15:14.42 |
| ray_laptop | beatmesiter2: from quick examination of Makefile, the default "prefix" for the install is /usr/local then gs goes in /usr/local/bin as do the scripts. We put stuff in /usr/local/bin/lib (presumably the .so files) and man files in /usr/local/share/man | 15:19.14 |
| | beatmesiter2: then there seem to be stuff going into /usr/local/share/ghostscript/... | 15:20.57 |
| | scared beatmeister2 away | 15:21.24 |
| henrys | ray_laptop:I reading something in Foley, van dam ... yesterday and noticed a picture of a calcomp plotter - I'd never noticed it before. | 15:22.45 |
| | s/I/I was | 15:22.52 |
| ray_laptop | henrys: probably the 512. They had one with chrome plated endcaps at CalComp in a 'museum' next to the demo room for visiting customers and others to see | 15:24.43 |
| henrys | it doesn't say - "flatbed plotter" | 15:25.54 |
| ray_laptop | I even did the code (in asm) on a 6800 for a "controller" that let people drive the old 500 series plotters from an RS-232 | 15:26.12 |
| | I have to dig out my Foley and look at it | 15:26.51 |
| | the 512 was the very first one. It had a drum about 6 inches in diameter and the paper was roll fed with hole punch on both edges. The 1/2 inch edges were perforated to tear off | 15:28.06 |
| | circa 1952 or 53 -- something like that. | 15:28.31 |
| henrys | meeting time. | 15:29.57 |
| | marcosw: do you want me to set up henrysx6 or do you want to login and do it. It should work now. | 15:30.35 |
| marcosw | henrys: I'll go ahead and do it. Is the ip address the same? | 15:31.14 |
| henrys | yes | 15:31.33 |
| mvrhel_laptop | good morning | 15:31.48 |
| marcosw | i thought it was 192.168.1.102, but that's not it. can you remind me? | 15:31.56 |
| henrys | marcosw: 103 | 15:32.03 |
| marcosw | thx | 15:32.12 |
| henrys | I was going to update the workflowy agenda for the upcoming meeting. If anyone had a chance to look at it and wants to add or subtract please chime in. | 15:34.26 |
| | other than that we need to get rid of this bugzilla spam. Is marcosw going to take that one? | 15:35.25 |
| marcosw | sorry, which bugzilla spam? | 15:36.52 |
| henrys | chrisl: so you've had some progress on mooscript? | 15:37.01 |
| chrisl | henrys: I'm getting it into a state where it can be built "normally" rather than half GS, half mupdf and then manual linking | 15:37.51 |
| ray_laptop | chrisl: so this will be in the gs tree (as 'psi' is) or at the ghostpdl level | 15:38.48 |
| Robin_Watts | chrisl: With gs as a git submodule of mupdf? Or with mupdf as a git submodule of gs? :) | 15:39.09 |
| chrisl | ray_laptop: at the moment it's at the ghostpdl level, ultimately, it will have to in the Ghostscript subdir | 15:39.22 |
| | Robin_Watts: at the moment I have a mupdf repo "inside" the ghostpdl one. | 15:39.48 |
| marcosw | henrys: right, the bugzilla spam, I'll deal with it. | 15:40.03 |
| Robin_Watts | ok. So you could make mupdf a git submodule of gs. | 15:40.09 |
| | and it wouldn't affect anyone who didn't specifically want mooscript building. | 15:40.29 |
| henrys | marcosw: I actually had a user of a closed bug complain to me. I guess he wants his fixed bug history kept clean | 15:40.36 |
| chrisl | Robin_Watts: maybe. I was trying to remember - I know we discussed whether to fork mupdf for it, but I can't remember what the result was | 15:40.46 |
| Robin_Watts | I'm not sure how well git submodules with submodules work | 15:40.58 |
| mvrhel_laptop | Robin_Watts: so there is a GhostDocs.apk and a GhostDocs_ok.apk in your directory... | 15:41.15 |
| Robin_Watts | mvrhel_laptop: GhostDocs.apk is the latest. | 15:41.25 |
| mvrhel_laptop | ok thanks | 15:41.29 |
| Robin_Watts | I kept GhostDoc_ok.apk as a fallback in case I broke something. | 15:41.38 |
| henrys | mvrhel_laptop: are you all set for next week? | 15:41.41 |
| Robin_Watts | There will be a new version coming later I hope. | 15:41.47 |
| mvrhel_laptop | henrys: I still need to figure out some docs to show, but with Robin_Watts fixes that will be much easier | 15:42.10 |
| Robin_Watts | marcosw: Thanks for the bmp vs pdf run last night. From the files I've looked at, it's pretty much just underlines that look different now. | 15:42.21 |
| henrys | mvrhel_laptop: no pcl numbers I can't produce stuff that doesn't require improving pcl - I guess optimize pcl is going on the agenda. | 15:42.50 |
| marcosw | henrys: I'll look into removing the spam comments entirely (may involve MySQL). | 15:44.03 |
| henrys | I like workflowy but it is weak in some areas, at text based agenda git controlled in DropBox would be much nicer, if we could figure out how to make that non-tech friendly. | 15:45.18 |
| | won't worry about that now. | 15:45.49 |
| | anything else for the meeting? I am just reviewing the agenda and open bugs and don't have much else discussion-wise. | 15:47.18 |
| marcosw | I've set a couple of bugs to blockers for the release, one is mine and is just checking to make sure a bug is fixed. The other is mvrhel_laptop's and isn't critical but would be nice to have fixed before the release (psdrgb output related). | 15:48.44 |
| paulgardiner | henrys: is it still worth my working on pulling out an office-viewer lib from the epage source - at least as far as a nice state to park what I've done so far? | 15:48.59 |
| mvrhel_laptop | marcosw: maybe I will look at that one on the plane to japan | 15:49.11 |
| henrys | paulgardiner: yeah that's what we agreed to last isn't it? | 15:49.32 |
| mvrhel_laptop | I want to get text search and hyperlinks in gsview this week | 15:49.35 |
| paulgardiner | henrys: Okay good. Just checking. | 15:49.44 |
| Robin_Watts | henrys, paulgardiner: yes, that's what I understood too. | 15:49.48 |
| chrisl | ray_laptop, mvrhel_laptop: we had a customer raise the problem of the pngalpha device not working "correctly" with PDF transparency yesterday | 15:50.01 |
| Robin_Watts | chrisl: I was confused by that bug report. | 15:50.23 |
| henrys | mvrhel_laptop: are you going buy a surface or something to demo gsview? | 15:50.30 |
| chrisl | Robin_Watts: in what way? | 15:50.39 |
| ray_laptop | chrisl: right. I commented on that. It's a pretty easy "fix" (enhancement) | 15:50.42 |
| Robin_Watts | Surely if a PDF file starts with a "draw the whole background to white", then it should have a completely opaque background? | 15:50.49 |
| chrisl | Robin_Watts: it doesn't | 15:51.03 |
| ray_laptop | Robin_Watts: I think the problem is that the default 'put_image' from the pdf14 compositor draws a fulll page image (or at least a dirty rectangle) | 15:51.37 |
| mvrhel_laptop | henrys: I had not thought about doing it on a surface. It is not winRT based but desktop based | 15:51.41 |
| ray_laptop | but the edges and interior alpha are ignored | 15:51.49 |
| chrisl | Robin_Watts: the problem is we render the entire page group to the device as an "image" | 15:51.50 |
| Robin_Watts | it doesn't start with a "draw whole background to white"? or it doesn't have a completely opaque background? | 15:51.57 |
| | the former. OK. I understand. | 15:52.34 |
| mvrhel_laptop | henrys: what I need to do is start scaling back what version of .net I build with and see how far I can push it | 15:52.36 |
| ray_laptop | The problem is that we push an image to the underlying device wihen the pdf14 POP_DEVICE is done | 15:52.42 |
| | I haven't looked at the file attached to the bug, since it's a known problem. | 15:53.19 |
| mvrhel_laptop | ray_laptop: we probably need to do what we did for the one customer where we copy the transparency buffer for their device? | 15:53.42 |
| | if I am remembering correctly | 15:53.49 |
| | s/for/to/ | 15:53.58 |
| henrys | mvrhel_laptop: I sort of imagined gsview and the mupdf windows app merging ... | 15:53.59 |
| mvrhel_laptop | henrys: well one is a windows 8 app for the store and one is a desktop app. we could add a distiller to the windows 8 app | 15:54.33 |
| | but they have different UI's but do share common code at one level too | 15:55.04 |
| | henrys: we can talk about this at the meeting. I can add it to workflowy if you want | 15:55.33 |
| henrys | mvrhel_laptop: you can use the FBS make system ;-) | 15:55.48 |
| Robin_Watts | mvrhel_laptop: We can't edit the workflowy - only henrys. Or so I thought? | 15:56.10 |
| mvrhel_laptop | oh | 15:56.16 |
| chrisl | ray_laptop: I just wondered if it was worth pushing the pngalpha thing up the priority list a bit..... | 15:56.19 |
| mvrhel_laptop | well henrys please add a small discussion item on this | 15:56.28 |
| henrys | mvrhel_laptop: I'll put it in right now but if people are big on group writing we can do that, last we discussed it you guys didn't want to. | 15:56.54 |
| mvrhel_laptop | I could not remember | 15:57.10 |
| | I am fine keeping it in your hands | 15:57.19 |
| chrisl | henrys: I thought workflowy didn't have "proper" version control? | 15:57.39 |
| tor8 | Robin_Watts: git submodule --recursive should take care of that | 15:57.42 |
| Robin_Watts | tor8: yeah, I just googled that. | 15:57.56 |
| | having mupdf as a git submodule of gs sounds like it might work. | 15:58.08 |
| henrys | chrisl: I don't know what it does for sharing. | 15:58.10 |
| chrisl | henrys: which is a recipe for chaos if we could all edit it! | 15:58.39 |
| henrys | chrisl: probably wild west | 15:58.43 |
| | mvrhel_laptop: and you ended up using C# in the desktop app, is that right? | 16:00.27 |
| mvrhel_laptop | henrys: yes | 16:00.43 |
| henrys | can I pull this down somewhere and see if it builds on linux with mono? | 16:01.02 |
| | meeting adjourned one minute late ;-( | 16:01.43 |
| marcosw | henrys: I've figured out how to deal with the bugzilla spam (I think), but I'll do it tonight when I can take bugzilla down to make sure my mysql hacking is being done on a non-changing database (and, yes, I will test everything on the staging server first). | 16:02.44 |
| | and with that I have to run. I'll be back this afternoon (PST). | 16:03.00 |
| mvrhel_laptop | henrys: It is in my mupdf repos in a branch called win_desktop. I suspect the UI stuff will not build since it is WPF based (xaml). That part may need to be reworked for linux | 16:03.05 |
| | The other classes should be ok | 16:03.24 |
| henrys | marcosw: when will you be working on henrysx6, I have a hardware change to do? | 16:03.28 |
| mvrhel_laptop | I need to head out. Have to drive daughter to school | 16:03.41 |
| | bbiab | 16:03.44 |
| ray_laptop | chrisl: sorry -- had a phone call. | 16:14.21 |
| | chrisl: since it is a customer issue, I'm not sure why it isn't at least a P2 enhancement. | 16:14.49 |
| marcosw | henrys: I everything on henrysx6 is done. You copied over the cluster directory from macpro, so that made it quick and easy. | 16:15.24 |
| chrisl | ray_laptop: I wanted to check at the meeting before upping the priority | 16:15.30 |
| ray_laptop | and being assigned to "support" isn't likely to get it fixed soon (Bug 695048, that is) | 16:15.56 |
| chrisl | ray_laptop: I did mark it as a dup of the original bug | 16:16.27 |
| | ray_laptop: am I missing something, or is this almost a copy and paste job from the bitrgbtag device? | 16:17.00 |
| ray_laptop | chrisl: since mvrhel_laptop it quite busy getting ready for .jp and with GhostDocs, I'll assign it to me and make it P2 | 16:17.43 |
| | chrisl: bitrgbtag doesn't accept alpha, and pngalpha doesn't use tags, so "no" | 16:18.01 |
| | chrisl: I assigned bug 687630 to me, bumped it up to P2, and transferred the customer # over to it. | 16:18.48 |
| chrisl | ray_laptop: Hmm, I thought I had put the customer on it, must have made a mistake :-( | 16:19.30 |
| ray_laptop | chrisl: np. Done now. And this looks like more fun than psdcmykog banding/page mode differences | 16:22.01 |
| chrisl | ray_laptop: :-) I suspect you are right! | 16:22.20 |
| ray_laptop | chrisl: BTW, I just checked and Soren is cc'ed on the older bug, so I can just put updates there. | 16:24.31 |
| | chrisl: thanks for bringing it up | 16:24.43 |
| chrisl | ray_laptop: I think that happens automatically when you mark duplicates | 16:24.57 |
| | ray_laptop: silly question: how does a device tell GS it wants a tag plane? | 16:25.29 |
| henrys | chrisl, tor8:I'm going to forward the urw stuff to you guys and let you respond - please copy me in. | 16:30.10 |
| | or we'll probably need all 3 of us to have a discussion about it, then one of us will respond. | 16:31.09 |
| chrisl | henrys: Ideally, I'd have thought we'd want to both add the Greek/Cyrillic glyphs to the GPL fonts *and* the Artifex OEM agreement (presumably that covers the 136 set?) | 16:33.08 |
| ray_laptop | chrisl: we track tags if the (gx_device *)->graphics_type_tags is set to GS_DEVICE_ENCODES_TAGS | 16:34.44 |
| chrisl | ray_laptop: ah, thank you | 16:35.12 |
| ray_laptop | if it is GS_UNKNOWN_TAG then we don't maintain the tag plane | 16:35.26 |
| henrys | chrisl: I don't know if we want to add them just to gpl fonts. We want to be compatible with URW for the 136 set, which you know more about than I. | 16:36.49 |
| | chrisl: I suppose it does no harm other than bulk | 16:37.11 |
| chrisl | henrys: that's what I mean - we want to add the extra glyphs to both fonts sets, so the 35 (GPL) fonts remain a subset of the 136 (commercial) fonts | 16:37.56 |
| henrys | and I didn't understand his first paragraph, do we have those cyrillic characters now in the 66 fonts? Did your testing show that? | 16:39.25 |
| | or is he saying he can give us that now. They've already baked those and they're ready to go. | 16:39.56 |
| | tor8:this gives you everything you need in mupdf font wise? | 16:41.02 |
| chrisl | henrys: well, first, the list we have (on #691213 ) only shows 49 fonts with Greek and Cyrillic glyphs, and when I spot checked a few, not all had the extra glyphs. I need to check again, I suppose | 16:41.14 |
| henrys | so I'll tell him add to both (GPL and Commercial) and we believe there are bugs in the existing release and reference the bug. As soon as I hear okay from you and tor8 I'll respond. | 16:45.08 |
| chrisl | henrys: TBH, testing this is a nightmare, because the names in their spreadsheet don't match the file names we have :-( | 16:46.16 |
| ray_laptop_ | mvrhel_laptop: question (for when you get back). Do you think it is kosher for the pngalpha device to remember the alpha_offset and use the alpha plane after returning code==0 from the inital target->put_image call | 16:47.00 |
| henrys | chrisl: if we are going to do this maybe it is time to bit the bullet and change our names back. | 16:47.02 |
| ray_laptop_ | mvrhel_laptop: or should I copy the alpha plane ? | 16:47.18 |
| henrys | chrisl: I expect there will be maintenance associated with the change we are requesting. | 16:47.29 |
| | ray_laptop: net problems? | 16:47.57 |
| chrisl | henrys: I didn't change the names in the 136 set - the file names from URW do not match the list from URW | 16:48.00 |
| henrys | chrisl: ugh, I thought you were talking about our renaming. | 16:48.46 |
| | are the urw names inside the fonts the same - easy script to change all file names to that. | 16:50.05 |
| ray_laptop | henrys: yes. I'm in a different room and apparently at the limit of the wifi range | 16:50.42 |
| | mvrhel_laptop: nm. I think I can just go ahead and output the unblended RGB with the alpha. I'll see how the image compares. | 16:51.26 |
| chrisl | henrys: I thought we were trying to keep the URW names, at least for the 136 set. Anyway, I think it's reasonable for us to expect that URW's own name mapping table would match their fonts! | 16:51.28 |
| henrys | you're talking about the fontnr not the Family Name or has that changed also? | 16:53.12 |
| chrisl | henrys: I think Family Name is okay in this set, but yeh, Fontnr is not the file name | 16:53.51 |
| henrys | the filenames use the fontnr and I wonder if that is some sort of code that might reflect rev. info and should change but I'm not sure. | 16:54.12 |
| chrisl | henrys: the fontnr strings do *not* match the file names we have | 16:55.07 |
| henrys | chrisl: yes I do believe the fontnr's change and reflect some code | 16:56.10 |
| mvrhel_laptop | back. ray_laptop: I think the pngalpha device needs a putimage proc | 16:56.14 |
| | iirc | 16:56.28 |
| chrisl | henrys: in which case we should get an updated spreadsheet with each release, which we don't seem to be getting | 16:56.43 |
| mvrhel_laptop | or put_image that is | 16:56.55 |
| chrisl | ray_laptop: most people seem to want only the "background" (i.e. the unmarked areas) to be transparency in the pngalpha output | 16:57.16 |
| henrys | chrisl: true but we can just forget about the filename and use the family name + style to identify the font. | 16:57.55 |
| chrisl | henrys: and that makes it a pain to review specific fonts - like the fonts from the list that claim to have Greek and Cyrillic glyphs | 16:58.48 |
| mvrhel_laptop | henrys: so what happened with all the discussion that we had last week. we had the two options. one was the earlier path with ghostdocs the other was that we have everything | 16:59.07 |
| tor8 | henrys: the list in the spreadsheet he attached covers all of the fonts we need for MuPDF and more | 16:59.14 |
| henrys | chrisl: I don't think they're going to change that but I can report it as an issue. | 16:59.45 |
| tor8 | we only need 14 of them for mupdf, so chrisl's woes with the font names are basically not a problem for mupdf | 17:00.08 |
| chrisl | henrys: I have to assume they maintain some kind of "file name" <-> "family name" <-> "industry name" mapping, all I'd like is that to be part of the releases | 17:01.16 |
| mvrhel_laptop | oh there is an email | 17:02.49 |
| chrisl | henrys: in the wider scheme of things: if we want PDF/Postscript compatibility, the PDF list Peter sent you is, I suspect fine. *IF* we want Microtype compatibility, we'll need the Greek and Cyrillic glyphs in all the 136 fonts. | 17:03.45 |
| henrys | chrisl: I'll report, I don't mean to be argumentative... but it just seems like the fontnr is just another level of confusion which we should completely ignore. | 17:03.57 |
| chrisl | henrys: we can't just ignore file names. | 17:04.32 |
| Robin_Watts | mvrhel_laptop: I don't think anything has changed since the end of the big discussion on skype. | 17:04.47 |
| mvrhel_laptop | right. | 17:04.53 |
| ray_laptop | chrisl: it's actually easier to send the actual alpha (0 to 255) rather than having to blend the RGB and just fudge the alpha with 0 or 1 | 17:05.24 |
| Robin_Watts | mvrhel_laptop: Miles sent an email saying that the discussion he was scheduled to have that afternoon had gone well, but implied that it hadn't been signed. | 17:05.31 |
| mvrhel_laptop | I just saw his email from the 13th. It went in the wrong mailbox folder for me. I had all these nice rules in place for sorting my mail and I have had to rewrite them since my machine crashed | 17:05.32 |
| | and that one did not get caught properly | 17:06.07 |
| chrisl | ray_laptop: but I'm not sure that's what most people actually want...... | 17:06.18 |
| | henrys: our Fontmap relies on accurately mapping font name to file name, so having that accurate from URW would be really helpful | 17:06.53 |
| ray_laptop | mvrhel_laptop: I'm doing a pngalpha_put_image. I decided to try the real alpha rather than having to fudge the 0/1 alpha and provide blended RGB | 17:06.56 |
| henrys | chrisl: if I had a script that pulled family name + style out of the font and named the font, I'd never need to know about the number. That's exactly what I did with PCL - and when I've had a problem I report to urw URWClassico-Reg is broken and they fix it. | 17:07.00 |
| mvrhel_laptop | ray_laptop: that is the way I would do it | 17:07.21 |
| chrisl | henrys: when we spoke of this a couple of months ago, we agreed to switch to keeping the URW file names....... | 17:08.10 |
| ray_laptop | chrisl: well, if we get a complaint about doing it right (as the PNG spec and examples provide), then we can look at adding an option that does the funky "collapsed alpha" mode | 17:08.16 |
| mvrhel_laptop | right | 17:08.37 |
| henrys | chrisl: that's when I thought the font number and the file name was static. I had no idea they were changing it until you told me today. We don't want changing font file names, do we? | 17:09.13 |
| | chrisl: I did it in pcl for readability | 17:09.44 |
| chrisl | henrys: TBH, I'm still trying to get my head around how URW work - I find the whole thing decidedly confusing...... | 17:10.27 |
| henrys | chrisl: yes it is completely screwed up. | 17:11.50 |
| | bb in a couple minutes | 17:12.58 |
| | mvrhel_laptop: I talk to miles today about ghostdoc I haven't heard if the deal went through, Robin_Watts might know. | 17:14.25 |
| chrisl | ray_laptop: I suspect that the preference for the pngalpha output, at least for those that know about such things, comes from the fact that "PDF transparency" involves so(!!) much more than alpha blending | 17:14.39 |
| Robin_Watts | henrys: I haven't heard anything since the mail of the 13th. | 17:14.57 |
| | If the last time is anything to judge by, it will take 2 days to get money to the liquidators. | 17:15.15 |
| mvrhel_laptop | chrisl: the blending at that point in the process is normal blending | 17:18.09 |
| | no special pdf types | 17:18.14 |
| chrisl | mvrhel_laptop: sure, yeh. What I meant was that more people would probably want genuinely "transparent" PNG images if the PDF transparency blending could be more closely represented by PNG transparency. | 17:20.20 |
| henrys | chrisl:I assume UFST compatibility would also need Hebrew, Arabic - ce fonts? | 17:25.01 |
| chrisl | henrys: yes, I think so. Also, a load of other weird glyphs. IIRC. I have a list of glyph names somewhere | 17:27.20 |
| | henrys: there are somewhere between 250-350 glyphs missing in each font, compared to the Microtype fonts. But I really do not believe we should consider that as a goal - I think we should try to get to what we need for the PDF spec | 17:30.29 |
| | I got a new SSD for my laptop from Amazon - and it was just posted through the letterbox. I'm glad it wasn't a spinning platter drive........ | 17:36.59 |
| Robin_Watts | chrisl: Yodel, perchance? | 17:37.47 |
| chrisl | Robin_Watts: Royal Mail, which was also a surprise | 17:38.15 |
| henrys | chrisl: if I go to the monotype site and select the PS3 136 Font set it only says latin for most of the fonts I've looked at, strange: http://catalog.monotype.com/family/oem-monotype/letter-gothic-fm-for-printers-only | 17:39.02 |
| | I got there from http://catalog.monotype.com/product - "printer fonts" | 17:40.31 |
| chrisl | henrys: I didn't check every single glyph in every font, so it's possible that cust 532's list of glyph names for each font has names that don't match actual glyphs. But I also suspect that a lot of the extra glyphs that definitely do exist in the Microtype fonts are a) there for PCL compatibility, and/or b) there because the MT glyph modelling makes them "just work" | 17:42.10 |
| henrys | chrisl: well I can choose the HP compatible printer product and still I just see Basic Latin for all the fonts. That can't be right. | 17:43.19 |
| chrisl | henrys: well, for example, I don't think "propersuperset" is a Basic Latin glyph, and that is one the the Microtype Helvetica has | 17:45.51 |
| henrys | chrisl: are you looking at the fonts by themselves or accessing them with the UFST code? | 17:46.57 |
| | in the PS3 config? | 17:47.06 |
| chrisl | henrys: for these tests, I use cust 532's Postscript interpreter, which uses the UFST | 17:47.52 |
| henrys | anyway I can safely get quotes from Peter now for cyrillic and greek in each ufst and commercial. When we through in arabic I think bulk is going to become an issue with the 136 if it isn't already. | 17:49.10 |
| | s/through/throw | 17:49.19 |
| chrisl | If you want, I can collate a full list of glyphs over the Greek/Cyrillic ones that we'd need to match the UFST/MT ones - but I think that's a pointless goal. | 17:50.53 |
| henrys | chrisl, no let's get some prices first then revisit. | 17:52.21 |
| chrisl | henrys: HAH! I think that's rather telling: the AFM files that come with the MT fonts, don't actually have metrics for all the glyphs you can access in the MT fonts | 17:53.15 |
| henrys | just basic latin I suppose | 17:54.02 |
| chrisl | henrys: yeh, looks like it. ~230 glyphs in each | 17:57.17 |
| henrys | tor8, chrisl:and what is the compatibility situation with acrobat out of the box do they have Cyrillic and Greek in the 14? | 17:59.43 |
| chrisl | henrys: I *think* Acrobat uses Windows TTFs for most (all?) the base 14 now, so they have Cyrillic, Greek and *loads* of others available in most of them | 18:02.25 |
| tor8 | henrys: what chrisl said. | 19:09.17 |
| ray_laptop | OK, I think I have the pngalpha_put_image working. | 19:21.15 |
| | It fixes Bug 693024 and the customer (200) bug 695048. | 19:22.04 |
| mvrhel_laptop | ray_laptop: nice. | 19:26.12 |
| | ray_laptop: do you know if there is some way to have ghostscript give me some page # information as I converted a ps file to pdf? I see that it does do page number output with ps2write as it goes through a pdf source file. I do understand that this is 2 different things but I didn't know if there was some way to make it happen | 19:28.06 |
| | just trying to get some decent feedback with gsview when we are distilling a ps file | 19:28.41 |
| ray_laptop | mvrhel_laptop: do you know of any pdfs that have an SMask type drop shadow at the edge. The examples in the bugs just have "hard" edges | 19:28.50 |
| mvrhel_laptop | ray_laptop:let me see | 19:29.24 |
| Robin_Watts | stars.pdf ? | 19:30.19 |
| ray_laptop | mvrhel_laptop: some PS files emit %Page: # infomation as they go through, but AFAIK, there isn't a way during the pdfwrite or ps2write. The page number progress from PDF comes from the PDF interpreter | 19:30.36 |
| mvrhel_laptop | right. that was what I was figuring | 19:30.49 |
| ray_laptop | Robin_Watts: I'll try. | 19:30.52 |
| Robin_Watts | mvrhel_laptop: Can you not work on the number of bytes consumed? | 19:31.06 |
| mvrhel_laptop | oh stars.pdf is an ugly one with patterns etc | 19:31.08 |
| ray_laptop | BTW, When I save the bug files to PNG with Acrobat, I don't get pngalpha | 19:31.20 |
| mvrhel_laptop | Robin_Watts: yes. I can do that and I have that working | 19:31.20 |
| Robin_Watts | ah, cool. | 19:31.29 |
| mvrhel_laptop | but I have one huge file here (the PLRM.ps) | 19:31.36 |
| | that part way through dies when I do it piecemeal | 19:31.49 |
| | it is going to be a bear to debug this | 19:32.02 |
| | so I was hoping to avoid that for the time being | 19:32.27 |
| ray_laptop | Robin_Watts: where is stars.pdf ? | 19:32.35 |
| | Robin_Watts: I don't see it with "find tests -name "Stars*" or in tests_private | 19:33.24 |
| mvrhel_laptop | ray_laptop: Transparency-DesignGuide.pdf | 19:33.52 |
| ray_laptop | mvrhel_laptop: thanks. | 19:33.58 |
| mvrhel_laptop | which I think is in the public stuff | 19:34.02 |
| | should have everything you could ever want | 19:34.10 |
| Robin_Watts | ray_laptop: Yeah, I can't find an unedited stars thing here. | 19:34.44 |
| ray_laptop | mvrhel_laptop: nope -- I don't see that one locally unless I just haven't pulled that in (I haven't pulled everything locally, yet) | 19:35.24 |
| mvrhel_laptop | ray_laptop: let me put it on casper for you | 19:35.44 |
| | ray_laptop: ok it is in my root directory | 19:36.58 |
| ray_laptop | mvrhel_laptop: thanks | 19:37.07 |
| mvrhel_laptop | ok. I guess I will bite the bullet and debug this thing | 19:38.15 |
| ray_laptop | mvrhel_laptop: thanks. Got it. | 19:40.20 |
| | phone call... | 19:40.25 |
| mvrhel_laptop | ok that is weird. | 19:57.04 |
| | it is working now | 19:57.07 |
| | but the text placement of the letters is wacky | 19:57.23 |
| | the vertical alignment of the letters within a word are not proper | 19:57.59 |
| | they sort of wiggle up and down | 19:58.09 |
| | so this is a PS file that I created using ps2write | 19:58.41 |
| | on the console | 19:59.10 |
| | and then I used pdfwrite with the API in the new gsview | 19:59.49 |
| | hmm lots of other little things I need to fix | 20:05.39 |
| | ok. heading out to lunch | 20:05.47 |
| Robin_Watts | mvrhel_laptop: vertical alignment of letters within a word wiggling up and down sounds like a mupdf type3 rendering bug. | 20:06.48 |
| | but I thought we'd fixed that. | 20:06.57 |
| mvrhel_laptop | Robin_Watts: when was it fixed? | 20:07.10 |
| | maybe I need to update | 20:07.17 |
| Robin_Watts | month ago? | 20:07.17 |
| mvrhel_laptop | when i get back I will update and make sure I have the latest | 20:07.39 |
| | Robin_Watts: thanks | 20:07.52 |
| Robin_Watts | np. | 20:07.57 |
| | Are they bitmap fonts? | 20:08.10 |
| | actually, scratch that, it could be any type, maybe. | 20:08.36 |
| | OK, so I have underlines and strikeouts etc plumbed through. | 20:13.12 |
| | but their sizes/positions are wrong. I have some scaling problems. | 20:13.24 |
| | but it's progress. | 20:13.35 |
| henrys | bbiaw | 21:01.18 |
| | Robin_Watts: are you around? | 22:45.09 |
| | marcosw: I see you're back in business on henrysx6 | 23:24.47 |
| | marcosw: well it seems to have crashed shortly after you're arrival, it is up again now. It is 13.10 so may not have the stability of the LTS systems. | 23:56.53 |
| | s/you're/your/ | 23:59.06 |
| | Forward 1 day (to 2014/02/19)>>> | |
IRC Logs