| | <<<Back 1 day (to 2015/01/21) | 20150122 |
| tor8 | Robin_Watts: https://github.com/ccxvii/mupdf/commit/f8eb384499f5b89e90cbbea961ba073536c49bc5#commitcomment-9394496 | 10:56.25 |
| Robin_Watts | yeah, he's right. | 10:57.11 |
| | I'll commit that. | 10:59.07 |
| kens | Yay! fixed the mswinpr2 device with my code, finally...... | 11:12.26 |
| tor8 | Robin_Watts: thanks. | 13:08.10 |
| kens | wow, GS on Linux has *way* more devices built in than on Windows :-( | 13:47.10 |
| chrisl | I'd think a lot of them would be "printer" devices rather than "file" devices - so not much point on Windows when you can just install the "real" printer driver | 13:49.57 |
| kens | SO far they've all been 'contrib' devices. I'm not going to try and test those, if they use gdev_prn_open or the vector device open_file_options then they 'should' work. | 13:50.55 |
| | If you don't specify FirstPage or LastPage they will work anyway. | 13:51.14 |
| chrisl | IIRC, the only slightly weird one in there is the pcl3 one - and all the contrib device are, indeed, printer device | 13:52.18 |
| kens | SO far everything looks OK, I can't test them of course. I htink the pcl3 one is on WIndows, and I checked it already. Unless I'm thinking of some other device | 13:52.58 |
| | Oh, obviously I am | 13:53.14 |
| chrisl | There is a device called "pcl3" and then a bunch of minor variations on the theme - hpdjplus, hpdjportable, hpdj310 etc etc | 13:54.55 |
| kens | There are som weird anomalies. THe Windows build includes bit, bitcmyk, bitrgb, the Linux build also cinludes bitrgbtags.... | 13:55.23 |
| chrisl | bitrgbtags is analogous to the customer 532 device, so it's on Linux so we cluster test it - it can go into Windows if we want | 13:59.32 |
| kens | Not really worried, I know the other bit* devices work | 13:59.51 |
| | I'm only going to dek check these devices I think, I did a thorough job with teh WIndows devices and it looks like most of them are based off gdev_prn_open, so thay shold all work OK as long as they don't do weird stuff like the mswinpr2 device. | 14:01.09 |
| chrisl | kens: well, when it reaches that point, I can always test the contrib devices for you - of course, I can't check the output, but I can see they don't crash | 14:08.09 |
| kens | Well, they won't crash (or at least they shouldn't!) but the FirstPage/LastPage stuff 'might' not work. | 14:08.49 |
| | And the only way to tell is (probably) to have a device to print to | 14:09.02 |
| chrisl | Precisely - I *may* be able to try the pcl3 output on my DeskJet, but that's all | 14:09.36 |
| kens | FWIW I noticed in passing that a fair number of our devices have the same problem with '%d' syntax as was complained about for pdfwrite, they produce an extra file of output with nothing in it (except some HP devices produce a reset in the file) | 14:09.59 |
| Robin_Watts | kens: If only we knew of a product that would do software rendering of pcl.. | 14:10.38 |
| kens | SwiftView | 14:10.46 |
| | Or GS of course | 14:10.56 |
| Robin_Watts | or pcl6? :) | 14:10.56 |
| kens | But that doesn't help at all with most of these devices | 14:11.16 |
| | I'm not even sure what a 'cif' device is.... | 14:11.53 |
| chrisl | Even those that are PCL based almost certainly won't work with our PCL implementation | 14:12.01 |
| Robin_Watts | I would hope it might work with pcl3. | 14:12.53 |
| kens | PLC3 might work, but that's the least of the devices to worry about | 14:13.11 |
| chrisl | No, *definitely* not. DeskJet PCL3 is *far* from being a subset of PCL5 | 14:13.25 |
| kens | THe device list on Linux runs to 26 lines | 14:13.38 |
| | 99,02If you assume 10 devices per line that's > 250 devcies99,99 | 14:14.01 |
| | Hmm, that came ou tin weird colours | 14:14.14 |
| | Fortunately a lot of them come through the ESC/P device, and that seems to be all OK | 14:15.13 |
| | Err make that ESC/V device | 14:15.33 |
| chrisl | kens: CIF is apparently "Common Intermediate Format" | 14:15.37 |
| kens | News to me :-) | 14:15.45 |
| | That says its a video format | 14:16.16 |
| | Really ? We output video ? | 14:16.25 |
| chrisl | That was the only CIF I could find..... | 14:16.43 |
| kens | Let me look at the device again | 14:16.57 |
| chrisl | "used by some digital cameras for either images or video" | 14:17.06 |
| kens | Oh, well maybe then | 14:17.18 |
| | SOurce says: | 14:18.41 |
| | CIF output driver | 14:18.41 |
| | The `Fake bitmapped device to estimate rendering time' | 14:18.41 |
| | slightly modified to produce CIF files from PostScript. | 14:18.41 |
| | So anyone can put a nice logo free on its chip! | 14:18.42 |
| | Frederic Petrot, petrot@masi.ibp.fr */ | 14:18.42 |
| chrisl | kens: FWIW, I make it 343 devices in a default Unix configuration..... | 14:19.31 |
| kens | Possible, I was only estimating | 14:19.43 |
| | some lines might have a lot of devices. | 14:19.53 |
| | I'm up to escp now | 14:20.21 |
| chrisl | Phew, I think I have my Windows laptop functioning again - but still "Installing 17 of 52...." updates <sigh> | 14:21.13 |
| kens | Didn't realise you'd broken it | 14:21.25 |
| | Did you see the Windows 10 consumer preview ? | 14:21.37 |
| chrisl | Well, I would argue I didn't break it, but it stopped booting just before my Christmas break | 14:22.01 |
| tor8 | kens: free for the first year to lure people in, then hit them with a subscription fee? | 14:22.12 |
| kens | Well that's pretty normal for Windows. | 14:22.15 |
| | Last night I had to 'fix' 3 different things on the home computer | 14:22.32 |
| chrisl | I haven't read much about Win10. I think things might still change quite a bit before the final release | 14:22.54 |
| kens | Admittedly one of them was 'why won't the pritner feed' to which the answer is 'because some twit has dropped a pencil into its innards...... | 14:22.57 |
| | The 'holographic display' amused me. | 14:23.18 |
| | OK so the PCL3 devices (eventually) call gdev_prn_open but it looks like they mess with the device after opening it, which might be a problem. | 14:33.04 |
| chrisl | kens: that device is the one that has a dependency on the PS interpreter, so I would say it's "broken" anyway | 14:34.59 |
| kens | Well I cna fix it I think. I probably should. | 14:35.23 |
| | FOr my stuff I mean | 14:35.28 |
| chrisl | I need to revisit that dependency on PS - it's *really* bad | 14:37.40 |
| kens | It certainly seems like a bad thing. How else can we input PCL6 and export PCL3 ? :-D | 14:38.12 |
| chrisl | Well, I may need to drive my DeskJet from a LaserJet driver.... or something | 14:39.37 |
| kens | I'm sure we'll find a customer that wants to do it..... | 14:39.52 |
| chrisl | Customers don't get contrib devices | 14:40.23 |
| kens | I *love* the informative description in the devices : | 14:40.46 |
| | Contents: Implementation of the abstract ghostscript device 'eprn': | 14:40.47 |
| | general functions and page layout | 14:40.47 |
| | Apparently the 'eprn' device is only used by the PCL3 device. | 14:41.07 |
| chrisl | Yes, I believe so | 14:41.25 |
| kens | Which makesthe abstraction kind of pointless | 14:41.38 |
| | Well, I believe I've 'fixed the pcl3 device for my code, I guess I'll need to checkout my branch to find out | 14:42.12 |
| chrisl | Possibly eprn abstraction makes things easier for some of the pcl3 sub-devices - there are quite a few of them | 14:42.46 |
| kens | Well, they all seem to go through pcl3_open which calls eprn_open so as long as I fix those two they should all be OK. Oh, I need to check get_params and put_params as well, to make sure they use the defaults | 14:43.39 |
| | (I'm sure thye wouldn't work at all if they didn';t, but still...) | 14:43.54 |
| chrisl | Well, given the relative size of the eprn/pcl3 device, I'm not inclined to try to audit it all | 14:44.54 |
| kens | No way! | 14:45.03 |
| | I did check through a few of them, and they look like mostly boilerplate | 14:45.19 |
| chrisl | And I don't think the original author is still interested, either | 14:46.00 |
| kens | Martin Lottermoser ? | 14:46.35 |
| chrisl | Possibly.... | 14:46.50 |
| kens | After 13 years, I doubt I woudl be either | 14:46.52 |
| | OK so the eprn device uses gdev_prn_get/put_params so that will work OK | 14:48.32 |
| | What's the 'correct' way to get the branch I'm working on from my repository on casper into my Linux VM. Preferably in a way which means I don't have to clone 'golden' from casper again afterwards ? | 14:52.53 |
| chrisl | Do you have your repo setup as a remote in the VM? | 14:54.02 |
| kens | I do, but I haven't actually checked it works. Its set up as 'kens' | 14:54.25 |
| | I also have a 'chrisl' and a 'henrys' | 14:54.34 |
| chrisl | So, IIRC, "git fetch kens" should get the new remote branches | 14:55.14 |
| kens | Hmm, OK let me see. | 14:55.23 |
| | man page looks right | 14:55.45 |
| | Hmm, but it doesn't work, loosk like my remote is wrong | 14:56.14 |
| | ah, mis-spelling | 14:56.37 |
| | OK seems to have pulled loads of stuff, lets see what's on my branch | 14:59.14 |
| chrisl | "git branch -a" will list all branches | 15:00.04 |
| kens | NP, it listed them when it fetch'ed from the repo | 15:00.24 |
| | Just seeing if my latest commit is there | 15:00.38 |
| | Hmm, to which the answer is 'no' | 15:00.54 |
| | I wonder if I forgto to push it | 15:01.03 |
| chrisl | The latest commit on your repo is: "update the mswinpr2 device for FirstPage and LastPage" | 15:01.34 |
| kens | Yeah, I just pushed the last commit | 15:01.47 |
| chrisl | Your commit for eprn/pcl3 isn't on your branch, it's on master | 15:02.20 |
| kens | Oh for pity's sake | 15:02.27 |
| | Can someone kill that please ? | 15:02.33 |
| chrisl | It's on *your* master | 15:02.50 |
| kens | <sigh> Not on a branch, oops | 15:03.07 |
| Robin_Watts | kens: For the avoidance of confusion, it's worth referring to the main repo as 'golden', yours as 'kens'. 'master' is a branch name, not a repo name. | 15:04.20 |
| kens | I did call it golden up above. | 15:04.45 |
| chrisl | I don't really like "golden" - that suggests "ready for release" to me..... but, hey..... | 15:05.45 |
| kens | I'm just syncing my branch to my master, then I'll push my branch, then revert the commit on my master. Then everything should be OK | 15:05.48 |
| Robin_Watts | chrisl: 'golden' is our public git repo. | 15:06.47 |
| | When commits hit that they are released, at least in some sense. | 15:07.08 |
| | That's why we never(*) force push to golden. | 15:07.22 |
| | (* for some definition of never) | 15:07.28 |
| chrisl | No, they are not "released" until we tag and ship. There are plenty of times when our golden repo master is not ripe from "prime time" consumption | 15:08.12 |
| kens | OK so I reverted the commit on my master. If I now pull or push, will everything on golden remain untouched ? Or should I squash the commit and the revert commit ? | 15:08.44 |
| chrisl | How did you revert the commit? | 15:09.17 |
| kens | git revert | 15:09.22 |
| chrisl | That doesn't undo commits | 15:09.57 |
| Robin_Watts | aargh. git revert is almost never what you want. | 15:10.00 |
| kens | Really ? | 15:10.10 |
| Robin_Watts | git revert makes a new commit that reverts a previous one. | 15:10.20 |
| kens | Indeed | 15:10.25 |
| | The two are back to back | 15:10.31 |
| | I could just reset to the last commit form chrisl I guess | 15:10.44 |
| Robin_Watts | "git rebase -i HEAD~10" and just remove the commits you don't want. | 15:10.53 |
| kens | Just delete the lines ? | 15:11.34 |
| | In the editor I mean | 15:11.41 |
| chrisl | Yes, removing the lines drops the commits from the rebase | 15:12.11 |
| kens | OK thought so, but didn't want to mess that one up | 15:12.28 |
| | Well, it all looks ok | 15:12.49 |
| chrisl | So you should now be able to "pull" from golden | 15:13.45 |
| kens | I'll try in a second, just forcing the PCL3 change over to my repo | 15:14.10 |
| chrisl | And everything should look the same..... | 15:14.21 |
| kens | "current branch master is up to date" | 15:14.44 |
| chrisl | Good, top commit is my spurious debug code one | 15:15.11 |
| kens | Yep | 15:15.17 |
| chrisl | Sounds good | 15:15.30 |
| kens | and my pull in Linux came up with the 2 files I wanted changed, so tha'ts good too | 15:15.31 |
| chrisl | Your device_subclassing branch still doesn't list the eprn commit...... | 15:16.18 |
| kens | Hmm, odd, | 15:16.32 |
| chrisl | Oh, actually, it is there, it's just a long way down | 15:17.08 |
| kens | It should be the last one | 15:17.19 |
| | I'm not sure how it orders those, it seems ot be backwards | 15:17.33 |
| chrisl | No, it's the "oldest" commit on your branch | 15:17.42 |
| kens | Probably because of the way I did it | 15:18.00 |
| | Not the best idea in the world | 15:18.07 |
| chrisl | Probably because of the direction of the branch rebase | 15:18.13 |
| | You can easily get it back to the top if you want | 15:18.27 |
| Robin_Watts | You rebased the branch on master, when that commit was on master, I'd guess. | 15:18.34 |
| kens | Yes Robin_Watts correct | 15:18.43 |
| | And I would like to correct the order | 15:18.48 |
| | Otherwise I'll end up with broken history/commits | 15:19.01 |
| Robin_Watts | Then git rebase -i HEAD~10 and just move the line. | 15:19.03 |
| chrisl | Probably rather more than 10...... | 15:19.19 |
| Robin_Watts | (where 10 may need to be more depending on how many commits you have on your branch) | 15:19.22 |
| kens | I wonder what editor it will use on Linux..... | 15:19.25 |
| | I'll probably need 50 or so | 15:19.31 |
| Robin_Watts | $EDITOR or $VISUAL. | 15:19.34 |
| chrisl | Probably vi unless you say otherwise | 15:19.41 |
| Robin_Watts | chrisl: Often nano on recent linuxes. | 15:19.53 |
| kens | nano woudl be better but I suspect vi | 15:20.10 |
| chrisl | Ugh, I dislike that even more than vi :-( | 15:20.12 |
| kens | $EDITOR is emtpty | 15:20.20 |
| Robin_Watts | kens: export EDITOR=kens_favorite_editor :) | 15:20.41 |
| kens | Hmm, the ordering of these commits makes no sense to me | 15:21.22 |
| Robin_Watts | When they appear in the editor, most recent is at the bottom. | 15:22.00 |
| kens | For me git log shows hte commit I want as the most recent one | 15:22.03 |
| chrisl | I'm looking at the list on the website | 15:24.00 |
| kens | I'm looking at git log | 15:24.09 |
| chrisl | So, I just pulled the device_subclassing branch from your repo | 15:24.50 |
| kens | And if I look with git rebase -i HEAD~60 I see it as the most recent commit | 15:24.51 |
| chrisl | The most recent commit on your branch in git log is: "update the mswinpr2 device for FirstPage and LastPage" | 15:25.28 |
| | And the same commit is the most recent in the rebase -i editor | 15:26.23 |
| kens | It didn't say that for me before, but now I've got a 'merge' in the log | 15:26.27 |
| | Essentially, I htink I broke my checkout | 15:26.50 |
| Robin_Watts | kens: git rebase -i and delete the merge. | 15:27.38 |
| | git logg -50 should give you a little ascii art diagram on the left. | 15:28.07 |
| | or gitk | 15:28.16 |
| kens | I htink I'm back seeing what chrisl did | 15:28.16 |
| | Hmm, well I don't htink its showing me enough 'pick's in vi | 15:29.13 |
| | Ah, its just vi's crazy UI | 15:29.43 |
| chrisl | Do you have a gui editor in your Linux VM? | 15:30.08 |
| kens | I think I'll do this in msys | 15:30.12 |
| chrisl | You'll still end up vi won't you? | 15:30.42 |
| kens | vim, but that's OK | 15:30.56 |
| chrisl | Should be vim on Linux, too | 15:31.10 |
| kens | Possibly, but I feel happier in msys | 15:31.28 |
| | I use it more | 15:31.31 |
| chrisl | kens: in your msys bash shell, can you run "cmd.exe"? | 15:34.32 |
| kens | Err maybe, just a minute, its busy rebasing at the moment | 15:34.47 |
| | 40/60 | 15:34.52 |
| | OK git log looks right now, let me try cmd.exe | 15:35.41 |
| | Yes, that works and produces what looks like a windows command shell | 15:36.01 |
| | Control-C gets me back to msys | 15:36.30 |
| chrisl | Indeed, so exit that, and then try "cmd.exe //c notepad.exe" and see if it still returns to the bash prompt immediately | 15:36.44 |
| kens | No, its waiting, just a moment while I exit notepad | 15:37.11 |
| | And gfoes back to bash on exit. | 15:37.22 |
| | That looks interesting :-) | 15:37.29 |
| chrisl | So, that might be an option to get you an editor you're comfortable with | 15:37.45 |
| kens | Yes, looks like that would work | 15:38.10 |
| chrisl | Reduce the amount you have to fight with vi/vim | 15:38.43 |
| kens | Which woul be nice :-) | 15:38.52 |
| | Canyou take a quick look at my branch now ? I think the ordering should be OK | 15:39.23 |
| chrisl | Yep, that looks like how you want it | 15:40.09 |
| kens | Great! thanks | 15:40.17 |
| rayjj | morning, all | 15:54.27 |
| kens | Morning | 15:54.32 |
| rayjj | Robin_Watts: thanks for the review. I pushed the plib fixes just now | 15:54.47 |
| Robin_Watts | rayjj: np. | 15:55.14 |
| rayjj | I noticed that plib is now added to the linux build. | 15:55.17 |
| | kens: there wasn't a bug for that plib problem was there ? | 15:55.43 |
| kens | I was going to say the commit looked good to me, it fixed the places I'd identified as problematic | 15:55.52 |
| | rayjj, no bug | 15:55.57 |
| rayjj | kens: ok, thanks | 15:56.05 |
| kens | Nor for the cdeskjet fix | 15:56.07 |
| | Possibly others that I've done in passing | 15:56.19 |
| rayjj | kens: is the FirstPage stuff getting close ? | 15:57.16 |
| rayjj | hasn't read all the logs yet | 15:57.33 |
| | oops. scared kens away ;-) | 15:57.49 |
| henrys | chrisl: urw don't make type 1 fonts but instead open type type 1 so they've remade all 35 in open type T1. Not sure how much this is going to bite us: http://www.adobe.com/products/type/opentype/opentype-T1-faq.html | 16:11.11 |
| | chrisl: fonts are in my home on casper with the strange name deliver_2013_06_25_otfstd.zip | 16:11.50 |
| kens | Can't be type 1 if they are OpenType, must be CFF | 16:12.34 |
| henrys | kens: looking at the fonts they are indeed type 1 | 16:13.30 |
| kens | Then I'm baffled by the open type reference | 16:13.47 |
| | Maybe I'm wrong but I thought OpenType only supported CFF | 16:14.19 |
| henrys | I thought that as well. | 16:14.54 |
| chrisl | The OTF docs only state CFF outlines, so...... | 16:15.48 |
| rayjj | FWIW, the default editor I end up with on linux is emacs (which I detest) | 16:16.26 |
| kens | It always shakes my confidence when a type foundry can't get terminology correct. | 16:16.33 |
| chrisl | It rather shakes my confidence that we should be buying "Postscript fonts" and they give us OpenType..... | 16:17.15 |
| kens | But henry says they are type 1..... | 16:17.35 |
| chrisl | Even if they *are* Type 1 outlines, Postscript does not support OpenType | 16:18.13 |
| rayjj | but gs does, right ? | 16:18.24 |
| kens | They are opentype fonts ? with type 1 outlines ? Mind-blowing | 16:18.45 |
| rayjj | hopes so because we've been telling people that for years | 16:19.01 |
| kens | Hmm, I can't open the ziip file | 16:19.07 |
| chrisl | rayjj: "sort of" and "mostly" would be the answer to that...... | 16:19.24 |
| rayjj | chrisl: close enough for marketing purposes :-) | 16:19.45 |
| kens | chrisl can you copy the zip file ? | 16:20.06 |
| chrisl | rayjj: the place where we fall down is in CIDFont substitution - you can't use a CFF OTF for CIDFont substition | 16:20.32 |
| | Erm, why does the file name suggest a date in 2013?? | 16:21.54 |
| kens | I assumed that's why henry said it was an odd name | 16:22.12 |
| | But can you copy it ? | 16:22.24 |
| henrys | chrisl: don't know maybe the change over to open type | 16:22.25 |
| rayjj | henrys: the file isn't readable | 16:22.26 |
| henrys | readable by group. | 16:22.35 |
| kens | Well *I* can't open it to copy it | 16:22.45 |
| henrys | are groups screwed up on casper. | 16:22.47 |
| | ? | 16:22.48 |
| rayjj | yeah, but 'group' is henrys | 16:22.49 |
| chrisl | Permission denied | 16:22.53 |
| rayjj | -rw-r----- 1 henrys henrys 2544110 Jan 22 15:54 deliver_2013_06_25_otfstd.zip | 16:23.09 |
| henrys | oh okay I'll fix it. | 16:23.22 |
| Robin_Watts | Try now. | 16:23.32 |
| | (made it gs-priv group) | 16:23.37 |
| rayjj | works no | 16:23.47 |
| kens | Yeah copies now | 16:23.50 |
| rayjj | now | 16:23.50 |
| kens | Well the zip is full of .pfb files | 16:24.21 |
| | So not OTF at all | 16:24.28 |
| | And they do appear to be genuine type 1 PFB encoded font files | 16:24.49 |
| chrisl | Yep, just Type 1 - jeez :-( | 16:24.59 |
| kens | Certainlky they are PostScript not OpenType | 16:25.03 |
| | So, really *quite* a misleading zip name | 16:25.25 |
| rayjj | henrys: so those are the ones with the extra glyphs ? | 16:27.12 |
| henrys | rayjj: yes | 16:27.30 |
| | chrisl: a cluster push might be enlightening | 16:27.48 |
| chrisl | henrys: we'll need to decide what to do about names again..... | 16:28.12 |
| henrys | chrisl: other than cry you mean. | 16:29.59 |
| chrisl | Well, after the crying | 16:30.18 |
| | I'm half tempted to say we keep the file names, keep the font names (whatever they are) and rely on Fontmap.GS - I don't know if that brings other implications | 16:31.03 |
| kens | rayjj bandheight/plib fix causes compilefail on cluster | 16:31.40 |
| rayjj | kens: I cluster pushed it and it was OK | 16:31.59 |
| henrys | chrisl: I'm fine with that. | 16:32.02 |
| kens | I just got he mail from the commit test | 16:32.09 |
| rayjj | oh, nm that was before plib was built on linux | 16:32.18 |
| Robin_Watts | http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=cad213c2d188e7461322ee6f810684bea5358235&project=ghostpdl | 16:32.24 |
| rayjj | I didn't realize it wasn't included | 16:32.29 |
| kens | rayjj :-) | 16:32.30 |
| chrisl | I fixed it, it worked! | 16:32.49 |
| | error: macro "emprintf1" passed 4 arguments, but takes just 3 | 16:33.18 |
| henrys | chrisl, kens : I wonder if urw is referring to font changes that came about with opentype conversion - if they've brought those changes back to the type 1 format? See the adobe link above? | 16:33.51 |
| kens | henrys that is possible I guess. | 16:34.12 |
| chrisl | henrys: that's still not excuse for having otf in the archive name! | 16:34.37 |
| Robin_Watts | henrys: I bet they have designed the font as an opentype to match the latest versions,and have exported a T1 from it. | 16:35.10 |
| chrisl | henrys: I'll do some testing and see if there are problems just using the Fontmap.GS to get everything "right". | 16:35.21 |
| henrys | Robin_Watts: yes that's what I meant, applied the changes documented at the adobe link and exported as type 1. but this is very odd. | 16:36.51 |
| rayjj | chrisl: you didn't commit the fix for the compile fail did you ? | 16:37.39 |
| chrisl | rayjj: well, plib didn't work on the cluster originally, I fixed that, and added it to the default build | 16:38.17 |
| | rayjj: but I haven't fixed the issue with your commit, no | 16:38.31 |
| | henrys: it may mean they don't use the hinting features that are available in Type 1 and not in CFF - so the Type 1 and CFF outlines match exactly | 16:38.59 |
| rayjj | chrisl: that's why I didn't understand your comment "I fixed it" | 16:39.27 |
| chrisl | rayjj: at first I thought you'd overwritten my fix in the source file | 16:40.01 |
| rayjj | chrisl: I'll push the fix for the compile fail. | 16:40.11 |
| | how come it is "Building GhostXPS" when all I asked for was 'gs' ? | 16:40.43 |
| chrisl | To test the XPS output | 16:41.04 |
| rayjj | I'm not going to wait for the results (now that I know it compiles) since a regression doesn't test plib anyway | 16:41.37 |
| chrisl | It should now at least do *something* with plib, which is why I added it | 16:42.16 |
| rayjj | chrisl: maybe one of the nightly runs tests all devices | 16:42.38 |
| kens | Presumably one of Marcos's scripts tests all the devices | 16:42.40 |
| chrisl | Yes, I thought marcosw said on Tuesday it runs on each commit - but maybe it was nightly | 16:43.14 |
| | rayjj: it seems it was you that added the URW fonts into "Resource/Font" and did so using file names derived from the actual font names - any recollection of the reasoning for that? | 16:45.54 |
| henrys | chrisl: I know that I did that in PCL because I didn't like that the filenames had no relation to the contents of the file. | 16:48.31 |
| | we might have agreed to do the same with gs... but I don't remember. | 16:49.38 |
| chrisl | It also may work better for Postscript resource enumerating, which is one area I have concerns about it | 16:50.18 |
| | I mean, personally, I *prefer* to have the file name match the font name, anyway | 16:51.37 |
| kens | OK the eprn/PCL3 device(s) seem to be working now | 16:59.09 |
| Robin_Watts | mvrhel_laptop: Are you here? | 17:29.44 |
| | We've just got a message to support chasing the message to support that came in on the 20th. | 17:30.35 |
| | "Getting Started with MUPDF using .NET" | 17:30.54 |
| rayjj | Robin_Watts: that's from cust #1, right ? | 17:31.14 |
| Robin_Watts | The only .net stuff we've got is yours, I think, so tor and I are probably touching our noses on this one :) | 17:31.24 |
| | rayjj: I haven't looked up the number, but it's possible, yes :) | 17:31.38 |
| chrisl | That's probably another argument for having GSView in a separate repo - it's never going to be a good "example project"...... | 17:40.00 |
| rayjj | chrisl_away: sorry I missed your question about the font naming. I don't recall exactly, but ISTR that some of the CET tests were happier when the contents of the directory matched the Resource name that was enumerated. The "Fontmap" approach is rather opaque. Also the enumeration logic is more straightforward (I suspect) | 19:14.11 |
| | Forward 1 day (to 2015/01/23)>>> | |
IRC Logs