| <<<Back 1 day (to 2013/11/19) | 2013/11/20 |
Micha` | The Right Way may be to add (yet another) {num_, max_, }blendmodes in pdf_device_s, and populate it with blendmode-only ExtGStates. | 00:05.51 |
| Alternatively, an inline ExtGState could be considered (directly putting a <</ExtGstate << /BM%d <</BM BlendMode>> >>) with %d equal to the group number. No new var, and pretty safe. | 00:12.30 |
| Ok, I've proposed something which at least can be safely applied. Good night! | 00:22.37 |
Robin_Watts | ExtStates can't be inline. | 00:27.39 |
| we need another num/max thing. | 00:27.55 |
Micha` | Ah? Er... It does work though :-P | 00:37.53 |
| Robin_Watts: Just checked with evince, acroread and mupdf, they all happily accept the blend mode specified in http://michael.cadilhac.name/public/inline-blendmode.pdf . I'm not sure we mean the same thing by "inlining" in fact. | 00:58.03 |
| Please have a look when you'll have the time :-) | 00:58.18 |
| Until then, have a good night. | 00:58.30 |
| (However, my patch proposal is still wrong though, as I print the /BM in the wrong stream) | 01:01.27 |
| (I'll get back to that tomorrow then) | 01:01.39 |
BarthezZ | Hmm, is there any history available which filetypes versions etc. are supported since what version of ghostscript? | 10:32.53 |
Robin_Watts | BarthezZ: only in the docs. What particular filetypes are you thinking of. | 10:34.52 |
BarthezZ | well I have some old instance of ghostscript on an EL5 faxserver, but I suspect the problem is that that version can't convert Pdf-1.6 files, but I can't find documentation to verify. | 10:35.49 |
Robin_Watts | BarthezZ: Well, broadly a PDF 1.6 file shouldn't be MUCH different to any previous versions files. | 10:36.48 |
| 1.4 gained transparency. | 10:36.59 |
| and 1.5 (IIRC) gained compressed object streams. | 10:37.08 |
| but you can easily have a 1.6 file that will actually read fine in a 1.0 viewer. | 10:37.29 |
BarthezZ | hmmmm oke | 10:37.38 |
Robin_Watts | but we fix bugs all the time. You'd be well advised to try the latest version if you can. | 10:38.13 |
chrisl | BarthezZ: for information like that, you need to look at the changelogs, but they're not exactly targeted at end users | 10:38.32 |
BarthezZ | yeah, everybody advises newest versions Robin_Watts :) But that's going to be quite a hassle to get ghostscript in our build and deployment enviornment for EL5 | 10:39.33 |
chrisl | BarthezZ: surely you can just try the PDF in Ghostscript "standalone" before trying to integrate it into your system? | 10:40.23 |
BarthezZ | true | 10:41.09 |
| ah... finally managed to get the error from our fax software | 10:41.18 |
| ERROR: /undefined in /BXlevel is returned from pdf2ps | 10:41.31 |
Robin_Watts | BarthezZ: Hassle or not, if you can't try the latest version, we can't help you. | 10:42.44 |
BarthezZ | I understand :) | 10:42.53 |
Robin_Watts | If you try the latest version on a PC and then feed the file through you can see if it will complete without error. | 10:43.35 |
BarthezZ | Yeha, just pushed to file to an EL6 machine with the stock GhostScript and it does work... | 10:44.02 |
| So it's worth the trouble to upgrade and get it integrated | 10:44.17 |
| thanks guys! :) | 10:44.25 |
Robin_Watts | chrisl: I raised the fact that jom doesn't work to build gs on their bug tracker, and they've accepted the bug. | 12:40.57 |
| so who knows, maybe it will get fixed. | 12:41.08 |
chrisl | Robin_Watts: I'd be astonished, but we'll see | 12:41.53 |
paulgardiner | tor7: another iOS commit on paul/master (ink annotations). Please check it over when you have a moment. | 13:05.23 |
tor7 | paulgardiner: are the 'arcs' really arcs, or just bezier curves? | 13:10.12 |
paulgardiner | Ah yes. s/arcs/curves/g ? | 13:10.41 |
tor7 | paulgardiner: I'm not convinced about changing textSelectModeOn into interactiveModeOn with an enum. the body of the function is just one big switch on the enum, why not just different methods then? | 13:11.01 |
| or is it because they should be exclusive? | 13:11.17 |
| (which is kind of implied by 'mode') | 13:11.41 |
| if I'm reading this right, modeOn pushes another view on top of the current page view which eats the input until modeOff is called? | 13:13.11 |
paulgardiner | They are exclusive, but still it might be better to have separate methods. I thought there was a lot of shared code, but it looks like not. | 13:13.21 |
| tor7: that's right | 13:13.33 |
tor7 | pushMarkupMode, pushInkMode, popMode ? | 13:13.37 |
paulgardiner | Well the pushing and poping is an implementation detail, and you'd never push multiple ones | 13:14.26 |
tor7 | (and maybe a stack, or just a 1-deep stack, with the UIView to remove?) | 13:14.27 |
| you might want more than one, if doing some sort of annotation which needs text input? | 13:15.02 |
paulgardiner | textSelectView and inkView have different interfaces too | 13:15.08 |
tor7 | then you'd push the "markup" view first, then the "fill in the text" view? | 13:15.18 |
| should the MuPageViewNormal really need to know? | 13:16.51 |
paulgardiner | I think it works best that way. It is how the links and search results are done. | 13:17.45 |
tor7 | consider if the toolbar is the one who knows about annotation editing, and about pages, and does the annotation editing view management? (just tossing out ideas here, feel free to disregard) | 13:17.50 |
| what you have might well be the easier, I'm having a hard time seeing (or remembering) the overall architecture anymore | 13:18.19 |
henrys | paulgardiner: curious if you are using the Xcode ide for writing all this and if you like it. | 13:18.58 |
tor7 | paulgardiner: anyway, in summary: rename s/arc/curve/ and maybe split the ModeOn/ModeOff switch into separate functions if you don't object, and the commit should be good to go | 13:19.39 |
Robin_Watts | henrys: I'm done with 801 for now, I think, and the psdcmykog stuff is all committed. | 13:20.06 |
tor7 | henrys: I'd be very very afraid for paul's sanity if he actually uses Xcode (and likes it) | 13:20.07 |
paulgardiner | henrys: Yes Xcode. Overall I do like it... especially because it writes most of the code: it constantly guesses at what I'm intending to write (mostly correctly). | 13:20.10 |
Robin_Watts | so I'm going to go back to whatever it was I was doing before. | 13:20.19 |
| Possibly the JNI bindings? | 13:20.24 |
paulgardiner | henrys: but I do dislike the difficulty finding anything in the menus | 13:20.26 |
| tor7: Come on! You always knew I was insane. | 13:20.51 |
tor7 | I've never had anything but struggle with Xcode 4 onwards... the UI is taking all the wrong turns, not to mention the bugs! | 13:20.56 |
Robin_Watts | They removed gdb in the latest version :( | 13:21.12 |
tor7 | paulgardiner: speaking of insanity, do you want me to bring the iPad 2 to the maui meeting so you can have an ios7 device? | 13:21.33 |
| paulgardiner: and also, we really need to refresh the ios developer account, it's about to run out in a couple of days | 13:21.54 |
paulgardiner | tor7: Thanks, but no. I will soon turn mine into an ios7 device. | 13:22.03 |
tor7 | paulgardiner: it's only collecting dust... | 13:22.34 |
paulgardiner | tor7: Yeah, I think we should refresh the account. Not sure whether we need to change the type of account or not. We seem fine with the personal one at the moment. | 13:22.44 |
henrys | chrisl: fonts are on the way ! | 13:23.39 |
tor7 | paulgardiner: apparently you can contact Apple to do an app transfer | 13:24.04 |
paulgardiner | tor7: I think I'd just stick it in a cupboard. Probably more likely to be useful to you (however much you hope otherwise) :-) | 13:24.05 |
tor7 | from one account to another | 13:24.14 |
| paulgardiner: alright, I'll leave it in the drawer then | 13:24.33 |
chrisl | henrys: excellent! I'll look them over when I get done with Adrian's problem...... | 13:24.41 |
tor7 | paulgardiner: but given the time schedule involved, I think we should probably renew the old account in any case | 13:25.09 |
paulgardiner | tor7: sounds sensible to me | 13:25.29 |
tor7 | paulgardiner: the other option is to just pull the app, and upload a new one. but then existing users will not upgrade automatically. | 13:25.51 |
| (not that we'd really worry about that, it being a free app after all) | 13:26.01 |
paulgardiner | tor7: if transfers can be done relatively easily then that sounds like a good option. | 13:27.05 |
tor7 | holy crap they charge a lot extra for the developer program in SEK | 13:27.30 |
| oh, that's the VAT on top | 13:29.06 |
paulgardiner | tor7: There. Updated with the changes you suggested. | 13:58.30 |
tor7 | paulgardiner: LGTM | 14:00.47 |
paulgardiner | ta | 14:01.38 |
Micha` | Robin_Watts: About "inlining"; I feel it is avoided in MuPDF, why is that? For instance, for this blendmode thing, I could just store in the resources /BM0 <</BM /Multiply>>, inlining the dict, and, if I want to avoid redundant /BMs, keep track of these in an int array (associating an index i with the blendmode of /BMi). However, I feel that the /expected/ way in the library would be to create a new ExtGState obje | 15:51.41 |
| ct containing /BM /Multiply, and use an indirect reference to it when defining /BM0. Am I right? | 15:51.41 |
| paulgardiner: Any opinion on that? | 16:02.29 |
tor7 | Robin_Watts: so, bug 693495 is a file using the base14 fonts but re-encoding them to cyrillic, which is a charset not supported by the base14 fonts. I can get around it by using other substitution fonts, but it's tricky to detect... the URW fonts we use as substitute fonts don't have much beyond latin-1 coverage. | 16:05.33 |
| chrisl: maybe you have some ideas? | 16:05.40 |
chrisl | tor7: not really - IIRC, the spec does not require cyrillic so it's really a broken file | 16:06.50 |
tor7 | chrisl: that was kind of my sentiment, but if it had been using anything other than Times and Helvetica, it would have worked... :/ | 16:07.36 |
chrisl | tor7: nevertheless, it is using something not guaranteed by the spec. We could ask URW about adding cyrillic glyphs to the fonts.... | 16:09.21 |
Robin_Watts | Micha`, tor7: sorry, was on phone. brb. | 16:11.15 |
paulgardiner | Micha`: What does Adobe Reader do? Always worth a look. | 16:12.37 |
tor7 | paulgardiner: I expect adobe reader will pick up c:/windows/fonts/times.ttf which does have cyrillic support | 16:13.27 |
Micha` | It does understand inlining, as for what it produces, not sure how I can check that. | 16:13.29 |
tor7 | paulgardiner: and cue me to stop working here, when I reply a question that wasn't aimed at me :) | 16:13.57 |
paulgardiner | I tend to run the results through mutool clean -d | 16:13.59 |
Robin_Watts | Micha`: OK, if you look at the pdf reference manual, the spec says: | 16:14.12 |
paulgardiner | tor7: :-) | 16:14.51 |
Robin_Watts | "dictName gs (PDF 1.2) Set the specified parameters in the graphics state. dictName is the name of a graphics state parameter dictionary in the ExtGState subdictionary of the current resource dictionary." | 16:15.08 |
Micha` | That's right, I do get that. | 16:15.28 |
Robin_Watts | Hence regardless of whether "it works" in Acrobat or not, that is NOT correct behaviour. | 16:15.29 |
| In addition, lots of things are explicitly forbidden from being inline. the spec says "must be an indirect object reference" | 16:16.25 |
paulgardiner | What appearance stream does Adobe Reader produce when you highlight text? | 16:16.27 |
| .. is what I meant. | 16:16.40 |
Micha` | Ah, but I'm not going against this spec. | 16:16.45 |
| Yes, there are places where an indirect object reference are required, I've seen that. | 16:17.06 |
Robin_Watts | Micha`: Your suggestion to use inline dictionaries for gs *is* against the spec. | 16:17.28 |
Micha` | Is the ExtGState dictionnary one of them ? I can't find that. | 16:17.34 |
Robin_Watts | Oh, I have no problem with you putting /GS0 << /BM /Multiply /Type /ExtGState >> in the Extstate resources dict. | 16:18.26 |
Micha` | Using, e.g., /Resources<</ExtGState<</BM0<</BM/Multiply>> >> >> is against the spec? | 16:18.37 |
paulgardiner | I imagine Adobe Reader will display incorrect PDF, but I would hope that it would create a legal appearance stream | 16:18.43 |
Robin_Watts | no, that's fine. | 16:18.43 |
| I have no problem with that. | 16:18.46 |
| the problem is that currently we don't have code to add even that :) | 16:19.05 |
| The nice thing about doing them as separate objects is that they can be reused. | 16:19.32 |
Micha` | Well I do have that here, with a num_ max_ mechanism. I'll suggest that on the bug report. | 16:19.40 |
Robin_Watts | Micha`: Take your time, polish the code, and we may well just adopt it. | 16:20.36 |
Micha` | That's right, but it is a compromise. Hence my question: is always-use-refs a philosophy that should be followed when proposing changes to MuPDF? | 16:20.49 |
Robin_Watts | I personally would prefer refs to be used in this case. | 16:21.04 |
Micha` | Yeah, I usually submit my patches too fast :-) | 16:21.31 |
Robin_Watts | but it varies. We are at pains not to use refs for simple stuff like /Length. | 16:21.38 |
| ExtGstates are a bit too big to be nicely readable inline, IMHO. | 16:22.04 |
Micha` | Here it is similar, no? It's just a dict with /BM /Multiply. | 16:22.11 |
Robin_Watts | Micha`: Yes, but that's an unusually small example. | 16:22.48 |
| tor7: I've just read that bug. | 16:23.24 |
| My knowledge of font encodings is poor, but it sounds to me like you're right, and the file is broken. | 16:23.45 |
| And unless we want to get additional chars added to our base14 fonts, we're stuck. | 16:24.06 |
| We *could* do a cleverer fallback thing. | 16:24.22 |
| (is falling back on a per-char thing a nicer or worse solution? I seem to remember being shouted at by Ken and Chris when this came up before) | 16:24.57 |
chrisl | You'd get horrible, non-matching glyphs/spacing etc etc | 16:25.32 |
Robin_Watts | chrisl: indeed. | 16:25.38 |
| but when the alternative is missing content, something is better than nothing, IMHO. | 16:25.58 |
chrisl | And people would just complain about that | 16:26.02 |
| And checking every encoding for every (or every "common") cyrillic glyph name sounds horrific! | 16:27.05 |
Micha` | Robin_Watts: Ah; so you are saying: in the usual cases, better off creating a new object that could be reused, but here, no point doing so. Although currently, the two other ExtGStates created also have a single field (CA and SMask) and use indirect references, so I'd probably follow that, just for consistency. | 16:27.57 |
Robin_Watts | Micha`: No, I'm saying that while you could argue that this case is small enough, I'd rather go for consistency and create separate objects. | 16:29.15 |
Micha` | Perfect. So it *is* a dogma. :-) | 16:29.43 |
Robin_Watts | Our dogma is to be as consistent as we can, unless we don't feel like it. | 16:30.26 |
| In cases where we are inconsistent, we almost always feel bad for a few seconds when someone points it out. | 16:31.01 |
Micha` | I'd root for that. Although using tabs for indentation... :) | 16:31.20 |
tor7 | Robin_Watts: per-char things are terrible (you'll get mixed font styles for punctuation and text, unless you take extra care) | 16:35.06 |
Robin_Watts | tor7: Right, but this would only kick in for things that would otherwise be omitted entirely. | 16:35.37 |
tor7 | and as chrisl said, scanning every font descriptor for which glyph coverage is needed is icky | 16:35.55 |
| I did take a look at the supposedly "Times" and "Arial" metric compatible fonts that google ships with ChromeOS | 16:36.35 |
Robin_Watts | Well, presumably we'd only scan the font descriptors when we fail to find a glyph. | 16:36.46 |
tor7 | Tinos and Arimo. sadly, they are very far from metric compatible... | 16:36.50 |
Robin_Watts | So we'd only be slow in the fallback cases. | 16:37.16 |
chrisl | tor7: my vote (at least as a first step) is to get henrys to sound out URW about adding the glyphs | 16:37.22 |
tor7 | Robin_Watts: by that time it'll be too late | 16:37.23 |
| Robin_Watts: but as a semi-fallback to a per-glyph solution it might be workable | 16:37.55 |
| Robin_Watts: or, hm, well, we do actually scan the encoding once but that's when we've already decided on the actual font file to use | 16:38.48 |
| I think getting URW to add more character sets would be the best solution overall though | 16:39.04 |
henrys | tor7:write up a description and I'll send it along | 16:39.39 |
tor7 | henrys: I'm no expert on cyrillic, but there must be a windows codepage for russian that we could use as a starting step | 16:40.32 |
henrys | tor7:they recently asked me if we wanted to buy arabic and hebrew, I thought that would be too conflicting ;-) I'll ask about cyrillic. | 16:41.59 |
tor7 | henrys: yeah, I think the need for cyrillic is probably much larger as well | 16:42.24 |
| it's not the first time this has come up | 16:42.31 |
| henrys: it's just for the Times and Helvetica families primarily, Courier a close second. | 16:43.07 |
| no need for anything beyond those 12 | 16:43.21 |
henrys | styles? | 16:43.31 |
tor7 | henrys: Regular, Italic, Bold, BoldItalic only | 16:43.44 |
chrisl | I required, as a starting point, we could look at the cyrillic glyphs that were added to and removed from the GS/URW fonts | 16:44.00 |
tor7 | Courier is easy to replace with any other monospaced font | 16:44.08 |
chrisl | s/I/If | 16:44.26 |
henrys | okay I'll put in a request for cyrillc to be added to those 12 fonts. | 16:45.18 |
| I'll get an estimate first of course and let you know if we can do it. | 16:45.42 |
tor7 | henrys: if it's pricy, feel free to drop Courier from the list (making it 8 fonts) | 16:45.51 |
Robin_Watts | Do we have the fonts in version control somewhere? | 16:46.00 |
| Every time we bloat the fonts by adding more unnecessary chars, that's bad for our footprint on embedded systems. | 16:46.31 |
chrisl | "Every time"? | 16:49.23 |
Robin_Watts | "This time, and every future time" then :) | 16:50.39 |
chrisl | Well, it's the only route to sane output, so, suck it up...... | 16:51.28 |
tor7 | Robin_Watts: some of them are in user/tor/core35.git, but only the initial font drop of type1s we re-received back in 2011 (and the fontforge scripts I use to convert them to CFF for embedding in mupdf) | 16:51.34 |
| Robin_Watts: but yes, I think it might be worth adding a separate fonts.git repo that has all the fonts version controlled | 16:52.18 |
chrisl | tor7: I have a git repo for the fonts, but it's in my user area: http://git.ghostscript.com/?p=user/chrisl/urw-ps-core35.git;a=summary | 16:53.38 |
Micha` | As a rule of thumb, if both Acroread and Poppler fix a faulty PDF in the same way, should MuPDF do the same? --- here I have Okular producing an Highlight with the QuadPoints wrongly ordered; Acroread and poppler do not care, MuPDF kind of fails. | 16:59.50 |
Robin_Watts | As a rule of thumb, we try to follow Acrobat. | 17:06.50 |
Micha` | Ok, thanks. | 17:07.24 |
ray_laptop | chrisl: cust 801 says that their Makefile produced by autogen.sh doesn't have HAVE_SSE2, but mine on linux does. Do wee trust that configure is getting this right ? | 17:16.20 |
Robin_Watts | ray_laptop: He just fell off the net. | 17:17.30 |
| ray_laptop: Are they generating the Makefile from autogen.sh? Or are they still copying the one in from the 9.10 release? | 17:17.56 |
ray_laptop | Robin_Watts: In the email sent about 9 hrs ago, Nomura-san mentions that it wasn't in the one that was produced by autogen.sh | 17:19.37 |
Robin_Watts | ray_laptop: OK. | 17:19.49 |
ray_laptop | Robin_Watts: so, maybe that means they HAVE_SSE but not SSE2. I'll ask them to grep the their Makefile for CAPOPT and to send that line (or their entire Makefile) | 17:21.17 |
| in the meantime, I may dig into how configure tests for that | 17:21.43 |
Robin_Watts | ray_laptop: Their original source included code that required SSE2, not just SSE. | 17:21.46 |
ray_laptop | Robin_Watts: that's what I thought | 17:22.05 |
| chrisl: please see logs for my recent question | 17:22.17 |
chrisl | ray_laptop: I'll check - I didn't actually write the test...... | 17:23.42 |
ray_laptop | chrisl: OK. I see where it is tested at line 2233 of configure.ac | 17:24.09 |
| ir looks like it wants to be able to execute: input1 = _mm_loadu_si128((const __m128i *)buf1); | 17:25.02 |
chrisl | ray_laptop: no, it doesn't run that, just compile and link | 17:25.45 |
ray_laptop | chrisl: Oh, I didn't understand what AC_LINK_IFELSE did | 17:26.52 |
chrisl | ray_laptop: do you happen to know what Linux 801 are using? | 17:27.36 |
ray_laptop | chrisl: no. I'll ask them to send us the log from their autogen.sh and the Makefile | 17:28.33 |
chrisl | You can check whether we should have HAVE_SSE by doing: gcc -dM -E - < /dev/null | grep SSE | 17:29.13 |
ray_laptop | chrisl: and I'll ask them for their linux version and gcc --version | 17:29.21 |
| chrisl: and I'll have them do that as well. | 17:30.01 |
| chrisl: on peeves I get: | 17:30.30 |
| #define __SSE2_MATH__ 1 | 17:30.32 |
| #define __SSE_MATH__ 1 | 17:30.33 |
| #define __SSE2__ 1 | 17:30.35 |
| #define __SSE__ 1 | 17:30.36 |
| Robin_Watts: Orikasa-san asked me to connect to him on LinkedIn :-) | 17:31.04 |
chrisl | ray_laptop: Yep, me too, on my main machine. But I have at least one VM here that has none of those set | 17:31.25 |
ray_laptop | He mentions that they are meeting today with Miles and Scott -- he didn't mention mvrhel | 17:31.40 |
Robin_Watts | ray_laptop: I suspect that they may not know that Miles and Scott are dragging a feral engineer along with them :) | 17:32.59 |
chrisl | ray_laptop: ./autogen.sh (or ./configure) CFLAGS="-msse2" might get 801 what they need | 17:45.41 |
| It *seems* that, at least on all my x86 Linux VMs, gcc does not enable SSE(2) by default....... | 17:47.01 |
ray_laptop | chrisl: oops. I just sent an email asking for the information we discussed. I'll send a follow-up to have them try that as well, unless you want to do the follow up message to them (reply-all to the email I just sent) | 17:50.04 |
chrisl | ray_laptop: no, don't send them the above.... | 17:50.21 |
ray_laptop | chrisl: OK. We'll wait and see what they say then ? | 17:50.38 |
kens | is off now, goodnight all. | 17:51.11 |
chrisl | ray_laptop: It looks like the pcl/xps configure isn't properly propagating the CFLAGS from the environment, so the above won't work :-( | 17:51.30 |
ray_laptop | chrisl: right, thanks for digging into this | 17:51.56 |
Robin_Watts | chrisl: AIUI, they are only looking at gs for now, not pcl etc. | 17:52.41 |
chrisl | Oh, I thought they were PCL and not GS..... | 17:53.09 |
ray_laptop | Robin_Watts: they have discussed ghostPDL with henry, iirc. | 17:53.14 |
| I think they want EVERYTHING we have :-) | 17:53.28 |
Robin_Watts | ray_laptop: well, that's good, because we want them to want EVERYTHING :) | 17:53.44 |
chrisl | If they are using just now Ghostscript, then the ./autogen.sh (or ./configure) CFLAGS="-msse2" should work - let me try it, though | 17:54.02 |
ray_laptop | and after the visit they'll probably want us all to move there | 17:54.03 |
| and they may lock mvrhel up in a dungeon ;-) | 17:54.53 |
Robin_Watts | marcosw: Morning. Did the psdcmykog stuff run last night? | 18:16.55 |
chrisl | ray_laptop: for Ghostscript the "./autogen.sh (or ./configure) CFLAGS="-msse2" solution does work. I need to look at fixing the ghostpdl script, though | 18:17.45 |
marcosw | Robin_Watts: I decided not to add the psdcmykog testing until I did more testing. I'll do it tonight. | 18:18.17 |
Robin_Watts | marcosw: Ah, ok, thanks. | 18:20.33 |
| When you have it in, and it's passed visual testing, let us know, and we can add some verification stuff to spot the color_usage bits being wrong. | 18:21.12 |
ray_laptop | chrisl: does that work assuming that their CPU supports SSE2, or does that enable the checking to work correctly ? | 18:27.41 |
| Robin_Watts: BTW, if you don't like the hack I have to paint a pattern into the buffer, we can just leave the buffer unchanged and just write it (since it won't match the zeroes we write when trusting the color_usage) | 18:29.13 |
| Robin_Watts: that might actually be more useful when I go a-hunting for problems with bmpcmp | 18:29.52 |
Robin_Watts | ray_laptop: I like the idea of painting a pattern. | 18:30.45 |
| That way in a bmpcmp it should be immediately obvious what the difference is. | 18:31.33 |
| and we can then rerun with a tweaked device to look at the actual difference. | 18:31.55 |
chrisl | ray_laptop: I'm not sure: it tells gcc that it should produce code for an SSE2 capable CPU. As I said, it *looks* like gcc doesn't enable SSE(2) be default on x86 platforms | 18:31.59 |
ray_laptop | chrisl: that's strange. How'd it get enabled on peeves I wonder ? | 18:33.18 |
chrisl | peeves is x86_64 | 18:33.31 |
ray_laptop | chrisl: ah. OK. | 18:33.40 |
chrisl | BTW, this is news to me, too! | 18:33.50 |
ray_laptop | chrisl: well, thanks for the help. Do you want to send the suggestion to them, or should I ? | 18:42.27 |
chrisl | ray_laptop: It's probably best you do it - I need to head out real soon...... | 18:43.07 |
chrisl | thinks: also keeps me off their radar a little longer ;-) | 18:43.26 |
| ray_laptop: I'm off now - if need be, I'll pick up with 801 in the morning, if they have more build questions (assuming they CC support!) | 18:48.59 |
ray_laptop | chrisl_away: they are quite good about cc'ing support! Thanks again (for the logs) | 19:14.11 |
henrys | tor7:now that I think of it URW will have no interest in doing cyrillic for GPL fonts - the AFPL fonts they'll do but that likely won't help you. | 20:45.33 |
| tor7: I can ask but I'm pretty sure there will be no interest | 20:45.56 |
| tor7:they will AFPL the work - no commercial use. | 20:47.43 |
tor7 | henrys: hmm, that's a shame | 20:49.12 |
henrys | tor7: we did have somebody add cyrillic then we pulled it out, because it was poorly done. I wonder if that work could be improved upon easily. | 20:50.51 |
| tor7:by a graphics artist or somebody that does such things | 20:51.36 |
tor7 | henrys: https://en.wikipedia.org/wiki/Doulos_SIL is a Times look-a-like with cyrillic coverage | 20:52.16 |
| but only in one font face | 20:52.18 |
| the google Arimo and Tinos fonts are open source, supposedly (but not in practice) metric compatible. we might be able to make them metric compatible, but they look rather different in style (more like droid serif/droid sans) | 20:54.16 |
henrys | tor7:well first I'll ask them about GPL, just to be sure. | 20:55.51 |
| we have to have that it's what Borat uses. | 20:57.16 |
tor7 | henrys: https://en.wikipedia.org/wiki/Windows_Glyph_List might be worth asking if they could do that coverage. it's what microsoft's fonts use so if we have that we should be gold for 99% of these cases. | 20:59.46 |
henrys | tor7:I prefer to move us closer to ufst compatibility chrisl_away recently did an analysis of missing glyphs and we can feed that to urw | 21:03.37 |
tor7 | henrys: put it on the agenda for much heated discussion :) | 21:05.38 |
henrys | okay | 21:05.54 |
tor7 | I think for PDF having windows compatibility makes a lot of sense, since a lot of apps tend to assume all windows fonts are always available and don't embed them | 21:06.05 |
| and having times/arial/courier clones with the full WGL4 character set would mean we can cover our bases for most font substitution woes | 21:06.43 |
| and let droidsansfallback be our CJK solution as we've done so far | 21:07.04 |
henrys | it's on the agenda I think ufst compatibility is going to be the same or more encompassing than windows | 21:10.16 |
| if that is your concern | 21:12.58 |
| tor7:this sil license is interesting | 21:15.39 |
Micha` | paulgardiner: Say, this is out of the blue, but should the fz_abs(stroke->linewidth - thickness) < SMALL_FLOAT statement, near line 1540 in pdf-appearance.c, read > SMALL_FLOAT? | 21:43.59 |
ray_laptop | henrys: you wrote "tor7:they will AFPL the work - no commercial use.", but AFPL does *not* deny us licensing for commercial use, and it does *not* deny compliant open source usage -- it *is* incompatible with GPL apps that charge money (parasites) | 22:03.32 |
| I don't think there is anything in our mupdf terms that require us to only release GPL (as there is with Ghostscript). And we could have a GPL release with GPL fonts (w/o cyrillic) and an AFPL release with cyrillic fonts (AFAIK) | 22:06.37 |
marcosw1 | Robin_Watts: you aren't still around by any chance are you? | 23:53.01 |
| Robin_Watts: didn't expect so. | 23:53.31 |
| Robin_Watts: for the logs: many of the regression files produce an empty file with the psdcmykog device, e.g.: | 23:53.51 |
| gshead -sDEVICE=psdcmykog -o testog.psd ./tests_private/comparefiles/Bug689740.pdf | 23:54.00 |
| I'll probably open a bug as well (it will help your closed bug count :-) ) | 23:54.38 |
| Forward 1 day (to 2013/11/21)>>> | |