| | <<<Back 1 day (to 2011/10/17) | 2011/10/18 |
| LaoLang_cool | Robin_Watts: cool! | 00:00.53 |
| mvrhel2 | good night Robin_Watts | 00:13.08 |
| LaoLang_cool | yes, have a good dream | 00:14.56 |
| arthurf | I was looking at doc/Projects.htm - but I don't think it's current. Is there a list somewhere of bite-sized development projects that Artifex would like assistance with? | 02:41.28 |
| CaneToad | I've got a ps file that views ok, but if I do this, it produces a pdf file that looks like a quarter of the page of the original ps file: | 05:00.24 |
| | gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=out2.pdf out2.ps | 05:00.28 |
| | what am I missing? | 05:00.31 |
| ray_laptop | CaneToad: probably the .ps file doesn't set the page size | 05:05.16 |
| | CaneToad: so you are getting the default 'letter' (or A4) page size and the .ps file expected to be printed on something larger. | 05:06.04 |
| | CaneToad: what does the first line of your .ps file look lile ? (does it say "EPSF") in the first line ? If so, -dEPSCrip of -dEPSFitPage may help | 05:07.32 |
| | CaneToad: if you run gs -- toolbin/pdf_info.ps ____.pdf where ____.pdf is the PDF produced from the PDF will print out the MediaBox info | 05:10.11 |
| vtorri | hey | 05:16.52 |
| | except tor, does someone know a bit how mupdf's Makefile works ? | 05:17.27 |
| ray_laptop | vtorri: you mean it doesn't just work "automagically" ? ;-) | 05:19.51 |
| vtorri | no :) | 05:20.00 |
| | there is something strange when creating cmapdump | 05:20.14 |
| ray_laptop | vtorri: I usually build on windoze, but if you let me know the problem, I can check on linux | 05:20.39 |
| vtorri | it compiles several files, but the link is done with only one object | 05:20.42 |
| | not really a problem | 05:20.51 |
| | it compiles | 05:20.55 |
| ray_laptop | vtorri: what platform are you on ? | 05:21.01 |
| vtorri | it's just strange to me that files are cmopiled but not used at link time | 05:21.12 |
| | linux | 05:21.14 |
| | can I paste 5 or 6 lines here ? | 05:21.26 |
| ray_laptop | vtorri: the cmaps are pickled into a special binary file that mupdf uses | 05:22.12 |
| | vtorri: go ahead and paste | 05:22.26 |
| vtorri | cc -Ifitz -Ipdf -Ixps -Iscripts -Wall -pipe -g `pkg-config --cflags freetype2` -o build/debug/pdf_annot.o -c pdf/pdf_annot.c | 05:22.34 |
| | cc -Ifitz -Ipdf -Ixps -Iscripts -Wall -pipe -g `pkg-config --cflags freetype2` -o build/debug/pdf_cmap.o -c pdf/pdf_cmap.c | 05:22.36 |
| | cc -Ifitz -Ipdf -Ixps -Iscripts -Wall -pipe -g `pkg-config --cflags freetype2` -o build/debug/pdf_cmap_load.o -c pdf/pdf_cmap_load.c | 05:22.37 |
| | cc -Ifitz -Ipdf -Ixps -Iscripts -Wall -pipe -g `pkg-config --cflags freetype2` -o build/debug/pdf_cmap_parse.o -c pdf/pdf_cmap_parse.c | 05:22.39 |
| | cc -Ifitz -Ipdf -Ixps -Iscripts -Wall -pipe -g `pkg-config --cflags freetype2` -o build/debug/cmapdump.o -c scripts/cmapdump.c | 05:22.40 |
| | cc -o build/debug/cmapdump build/debug/cmapdump.o -lfreetype -ljbig2dec -ljpeg -lopenjpeg -lz -lm | 05:22.42 |
| | as you can see, just after the creation of libfitz, 5 files are compiled, but during the link of cmapdump, only cmapdump.o is used | 05:23.17 |
| | as I said, it's not an error | 05:23.43 |
| | I just find that a bit strange | 05:23.51 |
| ray_laptop | vtorri: go ahead and paste | 05:25.01 |
| vtorri | hmmm | 05:25.11 |
| ray_laptop | vtorri: sorry | 05:25.18 |
| vtorri | :) | 05:25.25 |
| | i can paste as many times as you want :) | 05:25.45 |
| ray_laptop | vtorri: so, you just don't know why cmapdump.o may need to build things like pdf_cmap_load.o ? | 05:26.10 |
| vtorri | well yes, but : | 05:26.44 |
| | cc -o build/debug/cmapdump build/debug/cmapdump.o -lfreetype -ljbig2dec -ljpeg -lopenjpeg -lz -lm | 05:26.54 |
| | clearly says that pdf_cmap_load.o is not used | 05:27.06 |
| ray_laptop | vtorri: I haven't dug into it, but since the cmap binary data is "internal" any change to the format would need everybody to "be in sync" | 05:27.25 |
| | I'll have a look at the dependencies ... | 05:28.14 |
| vtorri | and same remark for fontdump :) | 05:28.45 |
| | also, small warning: | 05:29.30 |
| | xps/xps_xml.c: In function âxml_parse_documentâ: | 05:29.34 |
| | xps/xps_xml.c:379: warning: format not a string literal and no format arguments | 05:29.35 |
| | btw, i compile the 0.9 release, not the latest source code | 05:30.36 |
| ray_laptop | vtorri: net glitch -- sorry | 05:31.41 |
| vtorri | np | 05:31.49 |
| | hmm | 05:36.04 |
| | in fitz.h : | 05:36.09 |
| | #include <unistd.h> | 05:36.11 |
| ray_laptop | vtorri: fz_throw(error); is clearly a typo as the expected sequence is fmt, .... | 05:36.22 |
| vtorri | it does not exist with vc++ | 05:36.28 |
| | #define fz_throw(...) fz_throw_imp(__FILE__, __LINE__, __func__, __VA_ARGS__) | 05:37.04 |
| AlecTaylor | Which is more powerful [for a pdftoxml tool] MuPDF, Ghostscript, Poppler or xpdf? - By powerful I mean multi-language support, line and table detection &etc | 05:37.16 |
| vtorri | (in C99 part of fitz.h) | 05:37.17 |
| | arg | 05:38.17 |
| | forget about unistd.h | 05:38.23 |
| sebras | vtorri: scripts/cmapdump.c does #include a few .c-files, but when testing I can not see those .c-files being compiled (and neither should they be) when I make like this: make nuke && make verbose=true build/debug/cmapdump on tag 0.9. what command are you using to compile? | 08:30.39 |
| LaoLang_cool | hi | 09:02.53 |
| | is there an operation to let mupdf fit the width of window? | 09:03.06 |
| | fit the pdf to the window it's in | 09:03.20 |
| | fit the width of the pdf to the window it's in | 09:03.43 |
| | oh... fit the pdf to the width of the window that it's in... | 09:03.59 |
| | sorry for poor English... | 09:04.04 |
| Robin_Watts | vtorri: IIRC cmapdump.c includes a lot of files at the top so it can just be a single build. | 09:13.31 |
| | s/build/compilation step/ | 09:13.41 |
| | The extra files that get built may well be a side effect of the dependencies present in the Makefile, required to ensure that everything stays in sync. | 09:14.12 |
| tor8 | vtorri: what command do you use to build cmapdump? | 09:23.07 |
| kens | vtorri is marked as away guys | 09:23.27 |
| tor8 | kens: I just woke up, so replying to the IRC log :) | 09:23.42 |
| | anyway, I don't see anything odd like what vtorri described. building 'cmapdump' only compiles cmapdump.o and then links it. there are dependencies on pdf_cmap.c and pdf_cmap_parse.c, but not their object files so they shouldn't be compiled. | 09:25.55 |
| Robin_Watts | tor8: Looks like she's on the text branch if that makes a difference. | 09:26.47 |
| | context | 09:26.52 |
| tor8 | Robin_Watts: no makefile diffs on the text branch | 09:28.37 |
| Robin_Watts | context, sorry. She was talking about fz_try etc. | 09:28.56 |
| tor8 | LaoLang_cool: no such option exists in the mupdf viewer. | 09:29.18 |
| | you can press 'w' to fit the window to the page though! | 09:29.32 |
| | Robin_Watts: now you've lost me completely | 09:30.04 |
| Robin_Watts | She's on the context branch, if that makes a difference. | 09:30.23 |
| tor8 | it still shouldn't matter, if we're talking about the cmapdump stuff. the makefile dependencies haven't changed in ages. | 09:31.52 |
| Robin_Watts | The context branch DOES have some diffs, because of Memento etc. | 09:31.55 |
| | ISTR that memento had to be added to the dependencies of cmapdump etc ? | 09:32.24 |
| tor8 | let me check it out and see | 09:32.38 |
| Robin_Watts | has shiny SSD and WIndows 7. | 09:33.15 |
| | Do I keep bashing my head against the unforgiving planar wall, or do I waste the day installing windows 7 etc? | 09:33.40 |
| tor8 | http://pastebin.com/0Wv043EM | 09:33.47 |
| | Robin_Watts: that's on the latest robin/context branch | 09:34.10 |
| Robin_Watts | Fair enough. | 09:34.17 |
| tor8 | I've been bitten by build skew bugs often enough in my life that I try to make damned sure I got my makefile dependencies correct | 09:35.24 |
| | I'd vote for installing windows and let your brain stew in another kind of frustration for the day ;) | 09:35.47 |
| LaoLang_cool | tor8: I want pdf to fit the window, not the reverse! | 09:41.30 |
| | :) | 09:41.32 |
| sebras | LaoLang_cool: as tor8 said fit page to window is not supported in the current mupdf viewer. however, this feature will of course be considered when when the new viewer is written. | 09:50.29 |
| LaoLang_cool | sebras: is the new viewer being written? | 09:51.54 |
| sebras | LaoLang_cool: work has started, yes. no schedule for when it will be released or publicly accessible even as pre-release source code though. | 09:53.48 |
| LaoLang_cool | sebras: it's a good new! | 09:54.11 |
| | news | 09:54.13 |
| | thx for the hard work! | 09:54.32 |
| | w to fit the pdf to the window, W to fit the window to the pdf :) | 09:55.06 |
| Robin_Watts | Right. Reboot. bbl hopefully. | 11:34.28 |
| robin_watts_mac | Well, that's just bonkers | 12:31.39 |
| kens | not working ? | 12:31.46 |
| robin_watts_mac | I'm a SATA power connector short on my PSU. | 12:31.53 |
| kens | I note you are on the mac | 12:31.55 |
| | Oh dear.... | 12:32.10 |
| robin_watts_mac | so I dug around in my 'random bits' drawer and found a cable with a SATA power connector on one end, and a molex connector on the other end that obviously came with some harddrive or other. | 12:32.38 |
| kens | Yes I think I have some of those around. | 12:32.56 |
| robin_watts_mac | But the molex connector is the wrong gender! | 12:32.57 |
| kens | That's odd. | 12:33.05 |
| robin_watts_mac | As, I say, bonkers. | 12:33.14 |
| kens | Find a spare old drive/device, rip the Molex connnector off, and rewire the adapter :-) | 12:33.34 |
| robin_watts_mac | I unplugged my blu-ray writer. | 12:33.45 |
| | Will buy another adapter for that. | 12:33.51 |
| kens | Another good solution | 12:33.59 |
| robin_watts_mac | I am tempted to move email to thunderbird while I'm doing this. What email tool to you all use ? | 12:36.39 |
| kens | Eduora :-) | 12:36.59 |
| kens | is a Luddite, clearly | 12:37.13 |
| robin_watts_mac | has been using Messenger Pro on the Acorn, which has the advantage that it's COMPLETELY impossible to get viruses that way :) | 12:39.24 |
| chrisl | robin_watts_mac: I use thunderbird - mainly because I can use it on (almost) all relevant platforms..... it works - urm, well enough..... | 13:46.15 |
| | Oh, dear - low disk space warning....... | 13:46.37 |
| kens | Hi marcosw How's Mexico ? | 14:27.21 |
| | chrisl ? | 14:35.48 |
| chrisl | kens: here | 14:36.14 |
| kens | Can you remind me how we map from CID to GID with a type 9 CIDFOnt ? | 14:36.34 |
| marcosw_ | kens: mexico is fine, so far. The wifi works well :-) | 14:36.43 |
| kens | marcosw_ pleased to hear it | 14:37.03 |
| marcosw_ | I was worried I'd miss the Tuesday IRC meeting. | 14:37.14 |
| chrisl | kens: I can tell where it's done - give me a sec.... | 14:37.14 |
| kens | I replied to the support mail asking for contract details and forwarded it to Scott | 14:37.24 |
| | chrisl that would help, thanks | 14:37.35 |
| marcosw_ | kens: saw that. | 14:37.45 |
| kens | Never knew they had adepartment in India but I guess it makes sense | 14:38.11 |
| marcosw_ | I was telling Miles, Coke Light, Wifi, and 110/220V make a 6 hour layover tolerable. | 14:38.33 |
| kens | 6 hours :-( | 14:38.48 |
| chrisl | kens: ztype9mapcid() in zfcid0.c - if that's any hel | 14:39.00 |
| kens | Still better than sitting on an airplane on the stand for 9 hours | 14:39.04 |
| chrisl | s/hel/help | 14:39.17 |
| kens | chrisl I expect it will be I'll debug to that breakpoint, thanks | 14:39.18 |
| | Its actually for pdfwrite, but I think I need to know this. | 14:39.34 |
| | To solve the problem | 14:39.43 |
| chrisl | To be honest, ztype9mapcid isn't great, as it returns a charstring, I *might* have to add a function to retrieve just a GID | 14:41.07 |
| kens | I might need it. | 14:41.19 |
| marcosw_ | yup, only 2 flights a day from Mexico City to Huatulco. which is more than you'd expect for a town of only 33000 people. It's popular resort town, so lots of tourists. | 14:41.43 |
| kens | My problem is 'slots'. With regular CID fonts these are CIDs, but with teh type 8 font I have here the CID is > number of glyphs in the font, and that doesn't work | 14:41.48 |
| | type 9 font | 14:42.03 |
| | I was wondering if I could use the GID instead. | 14:42.11 |
| | But I think names are possible too, so maybe I cna use the charstring | 14:42.26 |
| | \temp\new.pdf | 14:42.41 |
| | oops, sorry | 14:42.49 |
| | Umm, its called from the interpreter, hmm.... | 14:44.20 |
| chrisl | Hmm, you might need whatever logic is hidden behind the pfcid->cidata.glyph_data() function pointer, then - I can't remember, offhand. | 14:44.35 |
| kens | yeah, that's what I'm about to look at | 14:44.58 |
| | That construct looks familiar I'm sure I've seen it in the pdfwrite code today | 14:45.21 |
| | Umm, that's weird it seems to be OK there, I obviously don't understand this code well enough. | 14:46.41 |
| chrisl | kens: Call to map the CID to a charstring originates in gs_cidfn.ps in the procedure called: "%Type9BuildGlyph" | 14:47.07 |
| kens | Yes, trouble is I don't want teh CharString. | 14:47.39 |
| | I was hoping to get a GID. | 14:47.47 |
| | But perhaps the problem is broken logic in the gxfcopy code. | 14:48.05 |
| | Which doesn't appear to cater for type 9 CIDFonts. | 14:48.18 |
| chrisl | Strange, they're not that uncommon | 14:48.36 |
| kens | Yes, but only pdfwrite really uses teh font copying stuff | 14:48.51 |
| | Like this, at least | 14:48.57 |
| chrisl | Yes, I mean, I'm surprised PDF has a problem with them, given how regularly they're used | 14:49.41 |
| kens | The PDF interpreter doesn't, its just pdfwrite. It's something to do with the odd mapping of the subset font. | 14:50.09 |
| | THe CID is 0xfed5 but the font has 0x2210 glyphs. | 14:50.26 |
| | pdfwrite is trying to track the glyph usage, but can't map from teh CID to the glyph | 14:50.56 |
| | I'm going to have to dig more into this. | 14:51.03 |
| chrisl | So it should used CID 0x00 then shouldn't it? | 14:51.05 |
| kens | And indeed it does, which has two problems. | 14:51.16 |
| | First it doesn't work (don't know why) and second it really doesn'rt work when you have 2 glyphs outside the range.... | 14:51.41 |
| | This isnt' a /.notdef situation | 14:51.53 |
| | Its pdfwrite's own internal stuff | 14:52.02 |
| | The glyph genuinely exists in the font | 14:52.16 |
| | and it looks like it has the same GID as the CID. | 14:52.27 |
| | But, the GID range is discontinuous | 14:52.41 |
| | or so it seems | 14:52.49 |
| chrisl | That is permissible, IIRC | 14:53.09 |
| kens | Absolutely. | 14:53.18 |
| | Well, I think so | 14:53.26 |
| | It is fro CMAP subtables | 14:53.33 |
| | I think in terms of GLYF the offsets of missing glyphs just point to the end of the previous glyph | 14:53.58 |
| | I'm not certain if that should report the number of glyphs as the number of entries in teh CMAP ro the number of glyph in the GLYF table. | 14:54.34 |
| | pdfwrite wants the GID to be lower than the number of glyphs in the 'font' | 14:54.49 |
| | and it isn't | 14:54.55 |
| chrisl | So this is Type 11 fonts, not Type 9? | 14:55.30 |
| kens | Err, they claim to be type 9, so I'm unsure | 14:55.51 |
| kens | goes to look | 14:56.01 |
| chrisl | Type 9 are PS outlines, Type 11 are TTF outlines | 14:56.23 |
| kens | In fact its a subtype CIDFontType0C | 14:57.30 |
| | But using FMAP type 9 I guess, so TT is me being daft | 14:57.49 |
| | Its not TT at all | 14:57.54 |
| chrisl | So, actually it looks like the CID range does have to be contiguous | 14:59.26 |
| kens | I'm a bit lost right now. | 14:59.41 |
| | The CID is definitely fed5 | 14:59.47 |
| | And there really are *not* that many glyphs in the font I don't think. | 14:59.59 |
| | I'll need to disassemble it to find out though | 15:00.09 |
| | But is only 6K so there really can't be that many | 15:00.43 |
| chrisl | Well, looking in the PLRM, is says: CIDCount: the number of valid CIDs in the CIDFont. Valid CIDs range from 0 to (CIDCount -1) | 15:00.58 |
| kens | I suppose there could be a lot of null entries for glyphs that would be small. | 15:01.22 |
| | I'll disassemble the font | 15:01.28 |
| | But it does work with rendering, so it must be basically OK | 15:02.30 |
| chrisl | This starts life as a PS file? | 15:02.42 |
| kens | No, a PDF | 15:02.51 |
| chrisl | I wondered if it could be using a GlyphDirectory to handle being a subset? | 15:03.42 |
| kens | There is a GlyphDirectory yes. | 15:03.53 |
| | THat's where its getting the outline from | 15:04.05 |
| chrisl | Ah, in which case the CID range doesn't need to be contiguous - lord what a stoopid hack! | 15:05.21 |
| kens | Oh, I think I may need to read up on that. | 15:05.38 |
| | cffdisasm just throws its hands up in horror with teh font | 15:05.51 |
| chrisl | It can be either a dictionary or an array - if it's an array, I think the length of the array gives you the maximum CID value, if it's a dictionary, you might need to trawl the keys to find the highest value. Not sure | 15:06.57 |
| kens | Hmm, this is not looking like fun, oh well it needs to be done. THere's a delightful 'fixme' in the source for this one :-( | 15:07.29 |
| chrisl | Well, it does look like a classic Adobe - "You *must* do it this way....... well, unless you prefer to do it this way instead......" | 15:08.36 |
| kens | I guess someone paid them enough money to write an exception, or their own engineers cocked up so they wrote it into the spec. | 15:09.10 |
| chrisl | It looks more like whoever write the CIDFont spec originally didn't think about subsetting and embedding, and GlyphDirectory was an after-the-fact hack to make it possible. | 15:10.21 |
| kens | I suppose that's possible too. | 15:10.33 |
| | I'm going to have to understand this code before I can figure out what to do.... | 15:10.46 |
| chrisl | Good luck...... | 15:11.44 |
| kens | Not going to be fun, its definitely a hole in gxfcopy.c (copied_glyph_slot) | 15:12.03 |
| | Its just assuming that the CID is in the range 0->num glyphs | 15:12.25 |
| | Which is clearly wrong in the case of a GlyphDirectory | 15:12.37 |
| | Worse, the 'slots' are an array whose size is defined as the number of glyphs in the font. | 15:13.17 |
| | I guess I need to map the CID/GID to the entry in teh font. I'm not sure that's possible but we'll see. | 15:13.51 |
| chrisl | Hmm, wouldn't it be sufficient just to get num_glyphs to be the maximum CID available in the font? | 15:15.11 |
| kens | Yes, but that will inflate the size of the array, which might get uncontrollable | 15:15.35 |
| | This file contains at least 5 ddifferent subsets of the same font :-( | 15:15.47 |
| | I might try it as a quick hack though :-) | 15:16.27 |
| chrisl | Well, the other option is a lookup table, which is also (potentially) bigger and slower | 15:16.48 |
| kens | The information gets used in teh code to get the outlines, so it must already be present, somehow | 15:17.16 |
| | I can see I'm going to be reading this stuff for a few days | 15:17.36 |
| chrisl | You could "just" recreate the GlyphDirectory for all such fonts, I supposed | 15:18.17 |
| kens | I think we already have it, its what seems to get used by the outline retrieval. | 15:18.48 |
| | But I say that having stepped through the code exactly once. | 15:18.56 |
| | SO its probably a mis-understanding. | 15:19.06 |
| | Anyway, I know where to go now. ma ny thanks for the refresher :-) | 15:19.26 |
| chrisl | I'll be back in that area myself, probably tomorrow........ | 15:20.52 |
| kens | might talk to you then in that case | 15:21.02 |
| | meantime, need to undertand it.... | 15:21.08 |
| chrisl | Well, I'm coming at it from a different angle, obviously, bug digging in a related area | 15:22.24 |
| kens | I suspect mine is unrelated, since its the whole font copying thing, but thre's bound to be some overlap | 15:22.59 |
| chrisl | Sure, I'm not actually interested in the mechanics of CC/CID/GID mapping, but I end up going through it to get to where I need to be..... | 15:24.26 |
| kens | yes, I'm not interested in teh mechnics, except for marking the glyph as used (I think) | 15:24.53 |
| chrisl | In the meantime, I'm trying to stave off a headache whilst eyeballing UFST vs FT vs AFS output.......... | 15:26.09 |
| kens | Well they'll never be exactly the same | 15:27.21 |
| chrisl | Yep, but it's difficult to filter out the noise accurately - in fact, it's harder in the QL tests than in comparefiles | 15:28.41 |
| ray_laptop | robin_watts_mac: I use Thunderbird | 15:41.27 |
| | and like it | 15:41.34 |
| robin_watts_mac | I use thunderbird on the mac, and like it too. | 15:41.52 |
| | I just didn't want to go through the trauma of moving if there was a better option. | 15:42.08 |
| | Aw hell. Sophos Enterprise Console won't install on the Home edition of Windows 7. | 15:42.27 |
| kens | Enterprise != Home ? | 15:42.50 |
| robin_watts_mac | Enterprise console is their central database thing; that one computer updates from sophos and distributes around all my others. | 15:43.27 |
| | Time to investigate this 'anytime upgrade' thing. | 15:43.45 |
| henrys | I just sent out an apology for late support, upon reading the inquiry I'm not sure I completely understand the question. | 15:44.42 |
| kens | which one ? | 15:44.59 |
| henrys | I just sent it to support he sent it to me privately | 15:45.26 |
| kens | Oh, will go look | 15:45.42 |
| | I understand it I think | 15:46.01 |
| henrys | good that makes 1 of us. | 15:46.14 |
| kens | its for font foundries like Morisawa | 15:46.17 |
| | who tie fonts to specific instances of an interpreter susing the serial number | 15:46.32 |
| | Want me to pen a reply ? | 15:46.59 |
| henrys | please do. | 15:47.08 |
| kens | OK, wiull have to do some research too, I'll do a holding email now. | 15:47.25 |
| robin_watts_mac | 120 quid to upgrade! Damn. Was only 30 quid if I'd bought it originally. | 15:47.52 |
| kens | Micro$oft for you | 15:48.09 |
| henrys | kens:we should get the font right? | 15:48.38 |
| kens | which font ? | 15:49.28 |
| | Morisawa (for example) encrypt the font with a vendor ID and a serial number of the rip when downloading the font. This prevents it being used on another rip. | 15:50.28 |
| | THey then use a custom operator to decrypt the font (which must be supported by the rip) | 15:50.47 |
| | the font machinery only ever sees the decrypted font. | 15:51.01 |
| henrys | right but if you are going to propose a way to support these fonts might we want to test it with a real font? | 15:51.37 |
| kens | But, these all rely on the rip returning a unique answer to serialnumber. Normally this isn't a problem, because either the software has a DRM module or a hardware dongle or something, and you return that. | 15:52.04 |
| | henrys, we cna't use the font without having the custom decryption code | 15:52.16 |
| | Which usually requires a contract with teh font foundry | 15:52.34 |
| | I did all this for 5D with Morisawa | 15:52.46 |
| ray_laptop | We don't have the license from Morisawa to do their special decryption. | 15:52.47 |
| kens | Indeed. | 15:52.54 |
| | But I suspect its not quite the same deal, since this is a CID font | 15:53.06 |
| henrys | oh I'd think they'd just use the encryption already in pdf. | 15:53.08 |
| kens | Its the font that's encrypted, not the PDF/PostScript | 15:53.26 |
| | Normally the font is downloaded to the disk | 15:53.40 |
| ray_laptop | maybe -- but with Morisawa you never know | 15:53.42 |
| vtorri | tor8: ping | 15:54.00 |
| kens | I knwo Morisawa do encrypt their CID fonts, but I seem to recall they use the Adobe method instead of tehir own now. | 15:54.04 |
| ray_laptop | kens: we _do_ have support for the disk downloading that some fonts use | 15:54.21 |
| kens | The catch is still that there needs to be a custom operator as well as a serial number | 15:54.33 |
| ray_laptop | it's that 'diskn' stuff | 15:54.40 |
| kens | ray_laptop : downloading is only part of the problem, the easy bit. | 15:54.46 |
| ray_laptop | well, the serial number isn't hard | 15:55.16 |
| tor8 | vtorri: hi | 15:55.17 |
| kens | Again, there's *muc* more to it than the diskn stuff, one of 5D's customers sourced us a whole load of fonts from different foundries and getting them all to work was a royal pain | 15:55.27 |
| | ray_laptop : if you kow where serailnumber ios done that would save me looking.... | 15:55.47 |
| vtorri | tor8: about my comment : i'm on linux, i donwloaded the 0.9 release, and just did "verbose=1 make" | 15:56.12 |
| | that's all | 15:56.22 |
| ray_laptop | is looking. it's been a while since I worried about it. I'll let you know shortly | 15:56.25 |
| kens | :-) | 15:56.38 |
| vtorri | tor8: i can paste the whole output if you want | 15:57.18 |
| ray_laptop | kens: the gs_cet.ps has an example of how to set a serialnumber using 'superexec' | 15:58.12 |
| kens | superexec is a bad thing. | 15:58.28 |
| | Is there no serialnumber callback ? That's how we tackled it in Jaws. THe customer then interrogates their hardware and gives us the number. | 15:58.58 |
| tor8 | vtorri: so what's the problem? the other files are needed for libmupdf.a ... the order files are compiled in is irrelevant | 15:59.29 |
| kens | Also, if Morisawa ever got the idea that the serialnumber could be changed by sending a PostScript program they would withdraw their contract. | 15:59.31 |
| | You're supposed to cerrtify that can't happen | 15:59.39 |
| tor8 | it only builds cmapdump because the next file after it in the list depends on the files cmapdump generate | 15:59.52 |
| kens | meeting time :-) | 16:00.12 |
| henrys | meeting time | 16:00.15 |
| tor8 | vtorri: try "make generated/cmap_cns.h" | 16:00.21 |
| ray_laptop | kens: the default GS_SERIALNUMBER is in base/gscdef.c | 16:00.25 |
| vtorri | tor8: well, i never said it was a problem, i just said it was strange | 16:00.29 |
| kens | ray_laptop : just found it. | 16:00.38 |
| vtorri | as i don't use parallal make | 16:00.43 |
| henrys | we'll do kens first so he can leave early. | 16:00.47 |
| kens | But I'm sure customers won't want to build umpteen binaries with different numbers in them. | 16:01.07 |
| vtorri | i thought the order of the compilation of the files was following a logical order | 16:01.12 |
| kens | henrys I have nothing for the meeting. | 16:01.17 |
| tor8 | vtorri: not really... the file after pdf_cmap_parse.c is pdf_cmap_table.c .. that one depends on the generated stuff so that's when it'll build cmapdump | 16:01.22 |
| kens | I finally finished the teext rendering modes stuff | 16:01.27 |
| vtorri | first fitz, then the 2 scripts, the pdf and xps | 16:01.30 |
| ray_laptop | kens: probably not. That's why I pointed out the 'superexec' method | 16:01.33 |
| henrys | how is text extraction - and I'm wondering if we should have some sort of api for it that could be consumed by viewer developers and used with search? | 16:01.40 |
| kens | ray_laptop : but then you'd need a cuustomised startup for every installation | 16:01.58 |
| | henrys I've done nothing new with text exraction | 16:02.12 |
| | But ray and arthur ford fixed a bug for me | 16:02.23 |
| | I still need to do UTF-8 output | 16:02.30 |
| vtorri | tor8: ok. I've looked at the make output as i want to integrate mupdf 0.9 in my autotooled project | 16:02.34 |
| ray_laptop | kens: to do it right, we should add a gp_serialnumber to our platform layer | 16:02.35 |
| henrys | tor8:things are looking really good with mupdf on several fronts but we need the demo. Can you respond to Scott's email? | 16:02.50 |
| kens | tor8 has suggested that we produce conssistent 'xml' code from btoh whcih seems best | 16:02.52 |
| | ray_laptop : yes, I believe we need to do this | 16:03.08 |
| tor8 | henrys: I've got a new api/data format for fitz text extraction, but the implementation needs more work since it's an O(N^2) complexity | 16:03.12 |
| mvrhel2 | yes, it would be good to get a response to scott's email before I turn up the heat on my contacts | 16:03.50 |
| tor8 | henrys: I'm close to having something we can show on the ipad without being embarassed, but it needs a lot more polish before app store distribution | 16:03.58 |
| | henrys: have you looked into this thing 'ad hoc' app distribution? | 16:04.11 |
| henrys | tor8:well give scott an answer he doesn't want to do sales without a demo? | 16:04.19 |
| tor8 | apparently there's some way to do custom app installs outside the app store from a web page of your own, but only for 100 copies or something | 16:04.38 |
| vtorri | tor8: is there some API break between mupdf 0.5 and 0.9 ? | 16:04.42 |
| tor8 | vtorri: no API break yet, but there will be once I've had time to fix the issues on the text branch and merge it | 16:05.30 |
| henrys | tor8:I really think it needs to be on the app store that's where folks expect it to be. | 16:05.34 |
| vtorri | tor8: thanks | 16:05.49 |
| henrys | Robin_Watts_Mac:anything for the meeting? | 16:06.21 |
| robin_watts_mac | Nope. | 16:06.28 |
| henrys | mvrhel2, ray_laptop, alexcher? | 16:06.52 |
| mvrhel2 | nothing from me. just pushing further on screen creation | 16:07.07 |
| | should have this wrapped up this week or early next week | 16:07.20 |
| henrys | kens and I will be doing support while marcos is gone if you notice an email lingering contact one of us. | 16:07.36 |
| alexcher | henrys: the unique ID is easy to implement in PS or C. Who is responsible for this project? | 16:08.00 |
| henrys | mvrhel2:do we have agreement on buffering planes and how the work is going to get done. | 16:08.03 |
| | ? | 16:08.05 |
| kens | alexcher which Unique ID ? | 16:08.31 |
| | The customer one ? | 16:08.41 |
| | How do you propose to have a serial number which is unique for every installation ? | 16:09.02 |
| | But persistent ? | 16:09.13 |
| mvrhel2 | henrys: I thinks so. Robin is going to create the operation to copy them all at once. I will make sure we do the buffering and have the data | 16:09.14 |
| henrys | alexcher:we were just discussing that before you joined. | 16:09.16 |
| | mvrhel2:okay | 16:09.26 |
| | tor8:I'd say mupdf app store ready is the top priority. We have some momentum now on the sales front and we should be out there pushing the product. | 16:10.52 |
| kens | support query for you henrys | 16:10.57 |
| ray_laptop | kens: I thought you and I agreed that we would change zserialnumber (in zmisc.c) to call gp_serialnumber (instead of the compiled in one). | 16:11.01 |
| alexcher | kens: perhaps, the executable can be patched before it is shipped to the user. | 16:11.24 |
| kens | ray_laptop : yes, that was my thinking I wonderred if Alex had a different idea. | 16:11.27 |
| mvrhel2 | tor8: how far out are you to having something? is it weeks or months? | 16:11.28 |
| kens | alexcher that's a horrible idea | 16:11.38 |
| henrys | tor8:and the "pusher" wants it in the app store ;-) | 16:11.48 |
| mvrhel2 | :) | 16:12.15 |
| tor8 | mvrhel2: dunno. it's been slow going, learning all the iOS framework cruft to do it properly | 16:12.26 |
| henrys | kens:yes I'll get the ghostpdl one after the meeting. | 16:13.40 |
| alexcher | kens: the number can be also stored in the resources. There's API to modify application resources. | 16:13.56 |
| kens | alexcher, having worked with Morisawa I can be certain they would not accept any solution involving storage of the serial number. | 16:14.48 |
| | And you are still leaving teh customer with the task of creating individual customised installations for every instal. | 16:15.15 |
| | Which has the opportunity to go very badly wrong and is extremely tedious | 16:15.32 |
| | Mostly customers integrate their own DRM and it would be better to allow them to supply us with a serial number | 16:15.50 |
| henrys | tor8:It doesn't seem like the kind of thing we can divide up but can you make this your full time concern and have others work on other mupdf issues? | 16:15.59 |
| kens | ray_laptop : do you want to tackle adding gp_serialnumber to the code ? If so I'll open an enhancement bug and assign it to you | 16:16.41 |
| ray_laptop | kens: please do -- it's really quite simple. I'll put in defaiult code for the major platforms | 16:17.29 |
| kens | Greta, I'll do it now thanks ray_laptop | 16:17.50 |
| henrys | kens:although I suspect the ghostpdl support question is pdfwrite, preserving the images ... | 16:22.44 |
| kens | henrys could be, but if pdfwrite sees one image it writes one image. | 16:23.10 |
| | There is an enhancement open to 'aggregate' consecutive images, but it slows the whole creation process for (normally) very little benefit, so I've never done it. | 16:23.49 |
| | ray_laptop : bug #692615 assigned to you | 16:24.32 |
| henrys | meeting done! objections? | 16:25.42 |
| kens | No, I'm good, thanks | 16:25.50 |
| henrys | except one open question to tor8 | 16:26.15 |
| kens | BTW henrys ? That business about the image being in the exact same structure may not fly depending what they mean. pdfwrite will always manipulate the image to some extent | 16:26.49 |
| | Why does GhostPCL stop sending image data when it encounters a blank line ? Is it faster ? | 16:27.50 |
| henrys | it doesn't I have not idea what he is talking about. | 16:28.13 |
| tor8 | henrys: already done, apart from some distractions now and then | 16:28.19 |
| kens | Oh :-) | 16:28.20 |
| | pdfwrite certainly won't break up images. Maybe his PCL driver has ? | 16:28.35 |
| | I'll look at the file tomorrow | 16:28.45 |
| mvrhel2 | tor8: the app store is already done? | 16:28.51 |
| tor8 | mvrhel2: full time priority to app | 16:29.28 |
| henrys | kens:If you need to look at it I'll make a bug I am waiting for him to answer my questions. | 16:29.35 |
| kens | I'll leave it then. Looks like lots of images in teh PCL from a cursory inspection | 16:30.02 |
| mvrhel2 | tor8: oh good. so maybe as you push along you come back with a time frame estimate | 16:30.59 |
| marcosw_ | robin_watts_mac and mvrhel2: did you have a chance to look at the lcms1 vs lcms2 differences? | 16:32.52 |
| kens | tor8 Raed wants an answer from you ;-) | 16:33.02 |
| tor8 | I'm in a bit of a design pickle though ... the "paged" scrollview on iOS doesn't work with zooming. it makes a hard assumption that the content to be paged is exactly one screen wide. which isn't a problem with 'fit-to-width' but does raise the question of how we should do zooming. | 16:33.04 |
| robin_watts_mac | marcosw_: No, sorry. | 16:33.11 |
| marcosw_ | only one of them seems like an issue. | 16:33.39 |
| kens | henrys FWIW the PDF otuptu has 8 images in it, I have no idea if the original PCL file has that many or not, but that is the entire content of the PDF. | 16:34.51 |
| | Heading off for a pizza now, goodnight all | 16:35.02 |
| ray_laptop | kens: when you replied to Peter about the serialnumber you didn't tell him the enhancement bug # (we usually put it in as a link) | 16:35.12 |
| kens | Drat sorry, do you want to follow up with that ? I need to run | 16:35.28 |
| ray_laptop | did I type fast enough ? | 16:35.30 |
| mvrhel2 | tor8: so you are just fixing issues that you have with iOS but this is not a new issue thing | 16:35.34 |
| kens | just. | 16:35.34 |
| ray_laptop | kens: OK. I'll let Peter know | 16:35.41 |
| kens | I cna do it later tonight if you like, | 16:35.41 |
| mvrhel2 | new feature thing I mean | 16:35.43 |
| kens | I'll check the IRC log | 16:35.46 |
| | Bye | 16:35.49 |
| tor8 | mvrhel2: I'm rewriting the old demo from scratch, to have a proper user interface that can scroll as expected of an iOS app. it also has a file/document chooser and outline view, and I want to add searching as well before sending it t the app store. | 16:37.19 |
| | and of course, then we're dependent on the good will and mercy of the apple app store lords for approval | 16:37.46 |
| henrys | why can't we put the partial solution on the app store now? | 16:38.52 |
| mvrhel2 | tor8: ok so I am guessing a month... | 16:39.06 |
| henrys | assuming we won't have to then wait when you are done with development. Upgrades should go straight through right? | 16:39.35 |
| | it takes like 10 days or something to get approved right? | 16:40.24 |
| mvrhel2 | I can't imagine the app not being approved | 16:40.42 |
| | no naked girls in it | 16:40.49 |
| | pushing something early makes sense then | 16:41.17 |
| henrys | well it takes 10 days off the schedule. | 16:41.56 |
| mvrhel2 | yes | 16:41.59 |
| | I agree | 16:42.03 |
| | that is a great idea | 16:42.13 |
| tor8 | mvrhel2: approval takes roughly 3 weeks from what I've heard | 16:42.33 |
| mvrhel2 | oh. then send it in now | 16:42.42 |
| tor8 | so we really don't want or can't do frequent updates | 16:42.53 |
| mvrhel2 | we have to wait 3 weeks with each update? | 16:43.34 |
| tor8 | pretty much. they treat updates the same as initial releases from what I understand. | 16:44.15 |
| mvrhel2 | ok. I see. what I am reading is the initial submissions and the updates take about 7 days | 16:46.23 |
| | so there is no advantage to pushing it early | 16:46.37 |
| henrys | sigh | 16:46.45 |
| mvrhel2 | so we have to rely upon tor8 coding fast to make up the time ;) | 16:47.16 |
| tor8 | indeed. we basically want it perfect before submitting to reduce the delay a pushback would cause. | 16:47.19 |
| henrys | yes it's more strict than naked women too... Human guidelines and all. | 16:48.13 |
| tor8 | and no using hidden or deprecated or secret API calls, and a bunch of other no-one-knows-what rules | 16:48.55 |
| | and not competing with apple's apps | 16:49.11 |
| mvrhel2 | that last one seems a bit uncompetitive | 16:49.31 |
| tor8 | hey, it's apple we're talking about | 16:49.43 |
| mvrhel2 | what are they scared of | 16:49.47 |
| robin_watts_mac | mvrhel2: It's our sandpit, so it's our rules. | 16:50.07 |
| | Apple weren't slapped enough as children. | 16:50.18 |
| mvrhel2 | :) | 16:50.25 |
| henrys | well we are competing with preview or whatever the pdf viewer is. | 16:51.37 |
| tor8 | henrys: well, we have a workaround for that -- include MuXPS :) | 16:51.55 |
| mvrhel2 | ok. tor8: I am going to start pinging my contacts then. this will probably take 6 weeks at best before we could possibly get a meeting at best. I am guessing things will be either approved and in by then or not approved due to the competitive issue | 16:52.08 |
| | that is if I am even able to get a meeting. some of these people I have not talked to in 20+ years | 16:52.39 |
| tor8 | and if the approval takes longer, we can do what we've done in the past and let marcos sync the app to scott's and miles' device | 16:52.48 |
| mvrhel2 | tor8: yes. oh yes having the capability to do XPS and PDF would be sufficiently different | 16:54.12 |
| | I would think | 16:54.27 |
| | tor8: thanks for the information. if I can help with anything let me know (i.e. working on XPS issues on your plate) | 16:55.25 |
| tor8 | mvrhel2: yeah, I haven't had time to look at those bugs so if you've got the time? | 16:56.11 |
| mvrhel2 | ok. once I wrap up this screen stuff I will take a closer look at them | 16:56.34 |
| | heading out for a bit. have to run my father up to his brothers. bbiaw | 16:57.19 |
| tor8 | the code in MuXPS should be largely the same but there may have been a few accidental bug fixes while porting to the fitz graphics library, so it may be worth comparing between the two | 16:57.21 |
| | the mupdf viewer can read xps files so you can just use the windows binaries off the download page | 16:57.59 |
| ray_laptop | think I (finally) have all the places fixed that were sensitive to when a GC happened | 17:05.19 |
| Robin_Watts | tor8: You here? | 18:41.02 |
| | Setting up msysgit on the new windows. | 18:41.20 |
| tor8 | Robin_Watts: y | 18:41.22 |
| Robin_Watts | do we checkout as-is, and commit Unix-style ? | 18:41.32 |
| | or do we checkout as-is, commit as-is? | 18:41.41 |
| | or checkout windows, commit unix ? | 18:41.48 |
| tor8 | always commit unix | 18:42.15 |
| | checkout as whichever you prefer working with | 18:42.24 |
| | I think I've set up the .gitattributes in both mupdf and ghostpdl projects to override to that setting | 18:43.12 |
| | with the "* text=auto" setting | 18:43.31 |
| kens | Thanks for doing the email to the customer rayjj | 18:45.21 |
| tor8 | argh, the lack of source code for the ios frameworks really makes debugging reference counting crashes a bit ... difficult | 18:45.30 |
| henrys | chrisl_away:I forgot to ask you at the meeting about the type 1 parser you now share responsibility for with alexcher? | 18:59.45 |
| ray_laptop | those bugs I found when I changed the timing of GC were really a surprise in that I'm surprised we never encountered them before. | 19:22.00 |
| chrisl_away | henrys: I've been busy with other stuff, and I didn't see much point in nagging alexcher about the type 1 parser until I could some real time to look at it. I'll hopefully get some time next week. | 19:28.25 |
| | alexcher: I suppose it's as good a time as any to remind you about sticking your Type 1 code on a public branch, so we can both bang on it......... | 19:32.03 |
| ray_laptop | henrys: I just committed the fixes for 691978. Should I go ahead and notify cust 531 (Phil) or let Ken do it tomorrow ? | 20:14.13 |
| tkamppeter | henrys, in Ghostscript for Ubuntu Precise (the one which gets released April 2012) I have switched to external liblcms2 now. So the Precise developers and testers (including myself) will test this configuration now. | 20:15.32 |
| | mvrhel2, ^^ | 20:16.32 |
| ray_laptop | does anyone know if the mac OS/X has the sys/systemifno "sysinfo(int command, char *buf, long bufsize)" function ? | 20:28.26 |
| Robin_Watts | looking | 20:30.51 |
| | Nothing matching that in /usr/include | 20:31.46 |
| ray_laptop | robin_watts: it would be in /usr/include/sys I think | 20:38.12 |
| | Now I have to find out how far back Windows has the Registry key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID | 20:40.12 |
| | of course, if I get an error from the registry, I can just return "42" :-) | 20:41.02 |
| | off to run an errand. BBIAB | 20:41.49 |
| Robin_Watts | ray_laptop: I checked recursively. | 21:08.08 |
| vtorri | what does ray_laptop want to do ? | 21:16.58 |
| ray_laptop | vtorri: I want to get a machine specific *something" I can use to pickle into a 32-bit integer (or maybe 31 bits in case some apps can't handle negative #'s) | 22:38.31 |
| | I found /usr/sbin/ioreg -c IOPlatformExpertDevice | /usr/bin/sed -E -n -e '/IOPlatformSerialNumber/{s/^.* "IOPlatformSerialNumber" = "(.+)"$/\1/p;q;}' | 22:52.31 |
| | but I prefer not to have to do a exec call with "/usr/sbin/ioreg -c IOPlatformExpertDevice" and parse the results to find the IOPlatformSerialNumber buried in the results | 22:54.53 |
| | ahh. stackoverflow comes through again. http://stackoverflow.com/questions/933460/unique-hardware-id-in-mac-os-x anser #4 looks close to what I need. | 23:01.43 |
| | Forward 1 day (to 2011/10/19)>>> | |
IRC Logs