| | <<<Back 1 day (to 2015/04/19) | 20150420 |
| hetakuso | A lot of the PDFs I've opened seem to have the document catalog in the Info field of the trailer, and the page tree in the Root field of the trailer | 01:52.47 |
| | This seems completely contrary to the standard. Is there an explanation of this somewhere? | 01:53.09 |
| | Seems that Info is supposed to have metadata, and Root should be the document catalog | 01:53.35 |
| | No... seems I'm reading them wrong. Sorry | 01:57.40 |
| astrodog | Don't suppose someone is around who wants to take a look at a jbig2dec problem? (It uses a private header from libpng... so it won't build against new versions) | 05:58.48 |
| chrisl | astrodog: that's fixed in the latest code | 06:16.07 |
| astrodog | chris: Any chance of a bugfix release for it? Trying to fix the FreeBSD port. | 06:19.28 |
| chrisl | astrodog: well, it wasn't really a bug.... there'll be a release in September, in-line with the Ghostscript and MuPDF ones. | 06:21.19 |
| | In the interim, you can grab it from here: http://git.ghostscript.com/?p=jbig2dec.git;a=summary | 06:21.42 |
| | Or simply pull in the modified file - jbig2_image_png.c | 06:22.18 |
| astrodog | Can we do that reliably against the dev branch? Little worried about ending up with things desynced. :\ | 06:23.40 |
| chrisl | In this case, only that file changed, and is really self contained. | 06:25.15 |
| astrodog | chrisl: Gotcha. So we should be pretty safe to just grab that file, and not have it change underneath? (That way the checksums and such line up) | 06:27.07 |
| chrisl | astrodog: I don't really understand that - checksums will change because the file has changed. But it shouldn't cause any problems with future merges etc | 06:28.08 |
| astrodog | chrisl: The checksum will change when we shift to this, but it should be stable past that? | 06:29.01 |
| chrisl | astrodog: what checksum? The one for that source file? | 06:29.30 |
| astrodog | Yeah. | 06:29.55 |
| chrisl | Well, I don't anticipate any changes in there before the next release, but I can't be absolutely sure | 06:30.22 |
| astrodog | Just figuring out if we want to just grab the whole file, and deal with checksums... or maintain a patch until the next release. | 06:30.44 |
| chrisl | astrodog: presumably you could grab the whole file and treat it as a "patch". Given how rarely jbig2dec changes these days (and especially how rarely these parts of jbig2dec change) I'd say there's not a lot of diference between the two options | 06:32.26 |
| | But it really depends on the preferred process for your distro | 06:33.50 |
| astrodog | chrisl: Basically... if we fetch it externally, we need a stable checksum on the thing we're fetching. If it's a local patch, we can do whatever we want, but it has to be maintained independently... so, knowing what you guys do... what do you think is easier? | 06:35.56 |
| chrisl | astrodog: I don't really understand what you mean by "stable checksum" - I can't promise that file will never, ever change again! But it sounds to me like your easiest solution would be to treat it as a patch | 06:38.31 |
| astrodog | chrisl: Thankfully, we only need to track it until the next release. | 06:38.51 |
| | chrisl: Will do. Is that the only file we need? | 06:39.01 |
| chrisl | Yes. There were other changes in the commit, but they were only to address some (benign) compiler warnings. | 06:39.42 |
| astrodog | Gotcha. Thanks. | 06:40.34 |
| chrisl | astrodog: here's a link for the revised file in git (the link is huge, hence the tinyurl): http://tinyurl.com/p438jro | 06:42.30 |
| | astrodog: and here's one for the diff for that file in that commit: http://tinyurl.com/pu2vq9j | 06:43.28 |
| astrodog | Perfect. Greatly appreciated. | 06:43.54 |
| chrisl | NP, and those URLs *are* stable, they won't change | 06:44.16 |
| rupert | hello anybody here | 10:04.49 |
| kens | Maybe | 10:05.07 |
| rupert | i generated the .so files for android app but its 37.9MB | 10:05.45 |
| | is there anyway to reduce it or perhaps remove some of the processors | 10:06.10 |
| | that is not used by android | 10:06.20 |
| kens | I presum ethis is MuPDF ? | 10:06.28 |
| rupert | yes | 10:06.34 |
| kens | Then I have no idea, maybe Robin_Watts can help | 10:06.53 |
| rupert | any ideas Robin_Watts | 10:07.15 |
| pedro_mac | rupert: is that a debug build? The Google Play version of muPDF has an installed size of 15MB | 10:10.37 |
| rupert | og right | 10:10.58 |
| | oh* | 10:11.01 |
| | ill double check | 10:11.34 |
| pedro_mac | nods | 10:11.53 |
| | I think the 15MB figure also includes the apk (which is 5.7MB) | 10:12.29 |
| rupert | i;m going to try building again | 10:12.59 |
| | much appreciated | 10:13.21 |
| pedro_mac | no problem - let us know how you get on | 10:13.50 |
| rupert | is that for all platforms - architectures | 10:14.41 |
| Robin_Watts | rupert: For Google Play we do 4 builds. | 10:15.12 |
| | 1 per architecture. | 10:15.18 |
| | hence each apk is 6Meg or so | 10:15.41 |
| rupert | which architectures do you include? | 10:16.01 |
| Robin_Watts | Each one gets a different number. | 10:16.17 |
| | So 70 might be armeabi, 71 armeabi-v7a, 72 x86, 73 mips. | 10:16.40 |
| | Then google play serves the appropriate one to each device. | 10:16.55 |
| rupert | what about mips64 and arm64-v8a. Do you not include those? | 10:17.53 |
| Robin_Watts | We do not, currently. | 10:18.04 |
| rupert | what about x86_64? | 10:19.04 |
| Robin_Watts | I've listed the 4 we support. | 10:19.17 |
| rupert | do you know the latest samsungs like s6, note4 or even the nexus 9 uses arm-v8 | 10:25.04 |
| Robin_Watts | rupert: and are perfectly capable of running armeabi, or v7a code, I believe. | 10:26.38 |
| rupert | oh right | 10:28.16 |
| LoSmilzoAP | Hi everybody. | 10:33.09 |
| | There's any mupdf developer? | 10:33.23 |
| | I found a file (the first in my experience) whit a little problem. | 10:34.05 |
| kens | If you have a quesion, just ask it, but be prepared to wait for a reply | 10:34.15 |
| | If you thnk you have foudn a bug, then please open a bug report | 10:34.30 |
| LoSmilzoAP | I was hoping to be able to report it without having to create an account on bugzilla. :-) | 10:36.17 |
| | The file is http://www.raspberrypi.org/magpi-issues/MagPi32.pdf | 10:38.25 |
| Robin_Watts | LoSmilzoAP: Are you running 1.7 ? | 10:39.24 |
| LoSmilzoAP | Only some problem (i.e the "also inside" in the cover page is not shopwed correct | 10:39.25 |
| Robin_Watts | Looks fine to be in the latest version. | 10:41.12 |
| LoSmilzoAP | No way to discover the version with the commandline? (like mupdf --version?) | 10:42.36 |
| Robin_Watts | mudraw -v | 10:43.57 |
| | If that works, it's 1.7 :) | 10:44.03 |
| | LoSmilzoAP: 1.7 was only released last thursday. | 10:45.01 |
| kens | Robin_Watts : I just got a funny from /usr/bin/gitpush.sjh it told me 'Index was not unstashed' | 10:45.44 |
| LoSmilzoAP | Ok, I can't compile the 1.7 source then i'm *not* the latest version (i'm on an old ubuntu 10.04 :-/ ) | 10:45.49 |
| Robin_Watts | Why can't you compile the 1.7 source? | 10:46.08 |
| LoSmilzoAP | Ok, i'm happy to know the latest work fine. | 10:46.11 |
| | I really like mupdf, is my default pwd viewer. | 10:46.38 |
| | Also on Android. | 10:46.44 |
| Robin_Watts | So, build it. It'll take you less than 5 mins. | 10:46.57 |
| LoSmilzoAP | I don't have some x11 library and i don't have the rights for installing. | 10:49.51 |
| | Thanks Robin. | 10:49.58 |
| Robin_Watts | LoSmilzoAP: Well, if anyone has built it, the X libs must be there on your system. | 10:50.22 |
| tor8 | LoSmilzoAP: yeah, missing the x11-dev package is going to be a pain to work around | 10:50.34 |
| Robin_Watts | And you don't need to install it for you to be able to use it. | 10:50.38 |
| chrisl | Not necessarily..... | 10:50.43 |
| kens | Robin_Watts : can you spare me a minute for some git help ? | 10:50.51 |
| Robin_Watts | kens: sure. | 10:50.58 |
| tor8 | but if you can build on another system, you can copy the mupdf binary (it's completely self contained) | 10:51.05 |
| chrisl | Possibly only the run-time libs are installed, not the ones the compiler can pull in | 10:51.07 |
| kens | I htnk a cluster push failed or seomthing, I got an error about 'index was not unstashed' | 10:51.42 |
| Robin_Watts | chrisl: But unless someone has just copied the binary onto the system, the linking libs must have been there at some stage. | 10:51.53 |
| kens | Then I had some '>>>>>>>>' lines in my code | 10:51.54 |
| LoSmilzoAP | I know, I build it some years ago, in another machine. | 10:52.02 |
| kens | Now when I try to do a cluster push it tells me that various files 'need a merge' | 10:52.13 |
| tor8 | Robin_Watts: in a boneheaded move, all the distros decided to split all packages into two: one regular (with binaries and libraries) and one developer (with the header files) | 10:52.23 |
| Robin_Watts | kens: yeah, that suggests that a merge has failed. | 10:52.40 |
| tor8 | which I think runs counter to everything linux was supposed to be at the beginning... | 10:52.43 |
| kens | Robin_Watts : yep, but now I don't really know what ot do | 10:52.51 |
| Robin_Watts | gitpush does not do a merge. | 10:52.53 |
| | Were all your changes committed? | 10:53.02 |
| kens | I haven't done any merges, so I'm confused | 10:53.04 |
| | No, I was in the middle fo doing some rework, so its not all committed | 10:53.18 |
| chrisl | LoSmilzoAP: you can build without X, and check whether the file works with the latest mudraw | 10:53.27 |
| Robin_Watts | kens: urk. | 10:54.06 |
| | kens: I think you need to sort the files out. Edit them back to sanity. | 10:55.00 |
| kens | I just checked back through my terminal window. I did a 'gitpush.sh' and it was OK< but I had compile errors. SO I fixed those and did a gitpush.sh lowres and that's what gave me the 'Index was not unstashed error' | 10:55.06 |
| | Robin_Watts : they are (I believe) sane | 10:55.14 |
| Robin_Watts | So you've removed the <<<<< ? | 10:55.25 |
| kens | I have yes | 10:55.31 |
| Robin_Watts | Ok. | 10:55.38 |
| | Try a git stash ? | 10:55.43 |
| kens | Its says 'needs merge' on 2 files | 10:56.07 |
| Robin_Watts | OK. git add file1 file2 | 10:56.17 |
| kens | $ git stash | 10:56.23 |
| | gs/base/gdevoflt.c: needs merge | 10:56.23 |
| | gs/base/gdevsclass.c: needs merge | 10:56.24 |
| | gs/base/gdevoflt.c: needs merge | 10:56.24 |
| | gs/base/gdevsclass.c: needs merge | 10:56.24 |
| | gs/base/gdevoflt.c: unmerged (723b9b69db36bb798efc318757e16760bbc0ad9c) | 10:56.24 |
| | gs/base/gdevoflt.c: unmerged (a9837682e94ce5dc7880b1a5d3ba3b9370b1905c) | 10:56.24 |
| | gs/base/gdevsclass.c: unmerged (7dbe60a796cdc44ea3fec92012d2f7f137b542db) | 10:56.25 |
| | gs/base/gdevsclass.c: unmerged (319832c90401bdc3e39b23c6cbfe90927f336b93) | 10:56.25 |
| | fatal: git-write-tree: error building trees | 10:56.26 |
| | Cannot save the current index state | 10:56.26 |
| Robin_Watts | OK. | 10:56.33 |
| kens | Done | 10:56.53 |
| Robin_Watts | OK. so first thing we want to copy your changes away so they don't get lost. | 10:57.03 |
| | cp gs/base gs/kens_saved_base | 10:57.12 |
| | cp -r gs/base gs/kens_saved_base | 10:57.17 |
| kens | I can do that form WIndows :-) | 10:57.33 |
| Robin_Watts | Once that's done, let's force it back to sanity. git reset --hard | 10:57.46 |
| kens | OK copied (and also devices since I have changes there) | 10:58.18 |
| Robin_Watts | That should take you back to a clean state where git diff gives you nothing | 10:58.18 |
| | OK. | 10:58.22 |
| kens | OK so that's back to my last commit I thnk | 10:58.36 |
| Robin_Watts | Then copy the files back. | 10:58.40 |
| kens | Urk | 10:58.44 |
| | *all* of them ? | 10:58.50 |
| Robin_Watts | Yes. | 10:59.11 |
| kens | OK 1 sec | 10:59.15 |
| Robin_Watts | Is this a tree shared between windows and linux ? | 10:59.28 |
| kens | Yes | 10:59.45 |
| | Well, its my working ghostscript git checkout | 10:59.55 |
| | OK copied | 11:00.05 |
| Robin_Watts | I wonder if that's to blame for the problems. | 11:00.08 |
| | so git diff looks reasonable ? | 11:00.15 |
| kens | I've never had ths before | 11:00.18 |
| | Well ts a big set of diffs, but it looks more ro less OK | 11:00.32 |
| | I'd probably better try building I guess | 11:00.59 |
| Robin_Watts | I've occasionally had problems using git on windows, when it's "failed to unlink" files. | 11:01.08 |
| kens | Yes I've had that from time to time, I retry and its OK ususally | 11:01.26 |
| Robin_Watts | Those are due to MSVC holding onto the files. Retrying makes that work. | 11:01.29 |
| | yeah. | 11:01.31 |
| kens | Just doing a complete build, will take it a few mintues | 11:02.11 |
| | Well it built OK lets see what happens now.... | 11:04.31 |
| | stash works OK, so lets see about a cluster | 11:04.57 |
| | And it seems to be happy. Weird. Thanks Robin, I didn't really want to make it worse :-) | 11:06.00 |
| Robin_Watts | np. | 11:10.32 |
| norbusan | Hi everyone | 13:25.21 |
| | After bug 695934 I had some discussion with Chris, and wanted to ask one more thing about location of fonts for CID fonts. | 13:26.01 |
| | I was told that it is not a good idea to put ttf fonts in to the Resource/Font dir, but better put them into Resource/CIDFSubst and use special code to find the font. | 13:26.33 |
| chrisl | norbusan: hi - go ahead and ask | 13:26.38 |
| kens | Depends whether you want a Fontor a CIDFont | 13:26.49 |
| norbusan | For OTF fonts, how is the situation there? Should we put them into the CIDFont directory or also somewhere else? | 13:26.54 |
| | Sorry, all about CJK fonts .. | 13:27.04 |
| | so CID fonts with recoding etc .. | 13:27.10 |
| kens | Then you want a CIDFont | 13:27.12 |
| chrisl | OTF fonts are treated just like TTF fonts | 13:27.17 |
| kens | What Chirs said :-) | 13:27.29 |
| norbusan | Ahhh, so we should also not put them into CIDFont, but somewhere else. | 13:27.33 |
| kens | Or even Chris | 13:27.34 |
| norbusan | ;-) | 13:27.38 |
| kens | No, they should be treated as TTF | 13:27.47 |
| | SO they are entered in your cidfmap | 13:28.05 |
| chrisl | norbusan: indeed. Postscript no more undestands OTF than it does TTF | 13:28.08 |
| norbusan | Ohhh ... but it does indeed work without putting them into cidfmap! | 13:28.27 |
| | Surprised! | 13:28.32 |
| kens | You can put them i CIDSubst, but they may be anywhere you like | 13:28.34 |
| | 'work' for certain value sof working | 13:28.51 |
| norbusan | (hi Chris!) UK business hours, I am already after dinner glass of wine!) | 13:28.56 |
| kens | You should really use cidfmap because that way you know what you are getting | 13:29.19 |
| norbusan | Does that mean we should define for example for KozMin-Regular.otf the following: | 13:29.38 |
| chrisl | norbusan: It *sort of* works. The problem is without the cidfmap stuff, we don't have an ordering and registry to work with | 13:29.40 |
| | norbusan: in general, the vast majority of .otf fonts are really just Truetype fonts | 13:30.25 |
| norbusan | argg | 13:30.35 |
| | using backward slashes instead of forward now ... interfers with IRC | 13:30.50 |
| kens | :-) | 13:30.55 |
| | Happens to me all the time..... | 13:31.01 |
| chrisl | norbusan: it's often best to use a pastebin type site | 13:31.11 |
| norbusan | \KozMinPro-Regular << \FileType \TrueType \Path .... \SubfontID 0 \CSI [(Japan1) 6] >> ; | 13:31.24 |
| | where the path is to the .otf file? | 13:31.44 |
| chrisl | Yep | 13:31.52 |
| norbusan | Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh | 13:31.58 |
| | GOing back to work .... | 13:32.04 |
| chrisl | The exception is the rare OTF/CFF font (OTF with CFF outlines), and those we cannot use as CIDFont subsitutes | 13:32.40 |
| norbusan | Ok, but I guess I can check that with otfinfo | 13:33.39 |
| kens | It'll be an OTTO font if I remember correctly | 13:34.05 |
| chrisl | Probably. I suspect the chances of finding CJK fonts in that format in the wild is probably quite small | 13:34.17 |
| norbusan | Especially since we want to support good fonts only, anyway (Morisawa, Hiragino, Yu, Kozuka, ...) | 13:35.15 |
| | Since these are the fonts we also support in TeX (dvipdfmx,platex) | 13:35.32 |
| chrisl | Hmmm, "good" is a relative term..... | 13:35.45 |
| norbusan | Yeahhh ... | 13:35.53 |
| kens | Morisawa outlines are quite decent | 13:36.01 |
| norbusan | Yes. | 13:36.09 |
| | Hiragino, too. | 13:36.12 |
| kens | THough I've only seen those in old fashioned type 0 format | 13:36.16 |
| norbusan | Oh, cool! Never seen those, only in otf | 13:36.29 |
| chrisl | I was thinking more of the font internals than the outlines. I doubt there's a foundary out there I haven't had some strangeness come up with at some time or other | 13:37.30 |
| norbusan | Ah, well, that is a different world I guess. Agreed. | 13:37.50 |
| chrisl | But anyway, most people ship Truetype outlines now, unless you specifically ask for something else | 13:38.55 |
| | norbusan: and kens is correct, the first four bytes in an OTF/CFF font are "OTTO", so they are easy to identify programmatically, without requiring extra tools installed | 13:42.55 |
| norbusan | Oh,,, bummer | 13:43.40 |
| | Then we have some of them, actually, many ... | 13:43.49 |
| | But gs can work with them ... | 13:43.57 |
| | Huu? | 13:43.59 |
| | for example, HiraMinPro-W3.otf, available on most OSX, starts with "OTTO" ... | 13:44.25 |
| | what does that mean? | 13:44.28 |
| chrisl | GS can use them as fonts, but as far as I'm aware, not as CIDFonts. | 13:44.37 |
| kens | is uncertain | 13:44.58 |
| norbusan | We have font snippets in Resource/Font that loads these fonts with encoding: | 13:46.15 |
| | (HiraMinPro-W3-UniJIS-UCS2-H) | 13:46.15 |
| | (UniJIS-UCS2-H) \CMap findresource | 13:46.15 |
| | [(HiraMinPro-W3) \CIDFont findresource] | 13:46.15 |
| | composefont | 13:46.15 |
| | pop | 13:46.15 |
| chrisl | Erm, actually, no that can't be correct..... because I have an OTF/CFF I use for that..... norbusan: you're probably fine..... | 13:46.31 |
| norbusan | And we are loading the whole CID tables up to Sup 6 and display them properly ... | 13:46.39 |
| | @chrisl, what is correct? That one can use *both* types of OTF fonts in the TTF way, or that the OTTO fonts need to be used as CIDFont resource? | 13:47.20 |
| chrisl | norbusan: it is probably some specific OTF/CFF we cannot use as CIDFont substitutes. I have a bug report about it somewhere - a couple of OTTO fonts that shipped with a version of Windows caused problems | 13:48.24 |
| norbusan | Yes, indeed, we have found that, too. | 13:48.38 |
| | We usually check the PSName of the OTF fonts, and link it to the CIDFont/<PSNAME> | 13:48.55 |
| chrisl | norbusan: so just use the OTF files the same way you would the TTF ones | 13:49.04 |
| norbusan | No | 13:49.11 |
| | OTF files are linked into CIDFonts with link name of the PSName, and in Font/ snippets are generated | 13:49.50 |
| | TTF files are linked to FOnt (or now to CIDFSubst) and entries in cidfmap are created and snippets in Font | 13:49.51 |
| | So location of the links are different, and ttf has additional cidfmap lines added. | 13:50.23 |
| | otf fonts don't have anything. | 13:50.28 |
| chrisl | Oh, I see. That's probably why they work, then. We must be loading them as CFF CIDFonts, which will work | 13:50.57 |
| | But as I said, I think I use an OTF/CFF for substitution. I haven't looked at it in details since I looked at the bug I mentioned above. | 13:52.16 |
| norbusan | If someone is interested, here is the generated Resource/ dir from my script. It takes into account the fonts that I have installed on my system, so there are a lot: http://www.preining.info/Resource.tar.gz | 13:53.43 |
| | And, btw, I have checked all the Japanese OTF files I have, all of them are OTTO ;-) (I love the sound of OTTO, reminds of a strange northern German comedian) | 13:55.32 |
| chrisl | norbusan: why all the entries in Resource/Font with the composed font names? | 13:55.45 |
| norbusan | Good question. Not all of them are probably necessary, but some of them are, as we are using platex - dvips and the names come out like that. | 13:56.21 |
| | I am not sure whether *all* of them are necessary, but several. | 13:56.34 |
| | @chrisl probably you now understand my question about auto-composition ;-) | 13:57.11 |
| chrisl | Ah, so by rejigging where the TTFs are stored, you may not need all those any more | 13:57.46 |
| norbusan | Why? Most of them are for OTF fonts anyway? | 13:58.14 |
| rayjj | norbusan: by "auto composition" are you referring to our automagic 'composefont' step that combines the CIDFont name with the CMap name? | 13:59.05 |
| chrisl | Ah, well, dunno. But the interpreter should handle decomposing into the CIDFont name and CMap name | 13:59.09 |
| norbusan | rayjj: yes, that is what I meant, Use.html 8.3 (AFAIR) | 13:59.38 |
| | chrisl: but it doesn't work, at least my tests never found the font | 13:59.57 |
| kens | When GS can't find a font, one of the things it tries to do is sl;ice the font name into a potential CIDFont + CMap. It then looks to see if it has a CIDFont with that name, and a CMap with the CMap name. If it does, it composes the font for you | 14:00.03 |
| norbusan | Hmm, wait, I try it out ... | 14:00.27 |
| chrisl | norbusan: it should work *if* the registry and ordering of the CIDFont and CMap match | 14:01.22 |
| norbusan | How do I *check* the registry and ordering of a OTF OTTO font? | 14:02.37 |
| kens | Essentially, you can't. | 14:02.54 |
| norbusan | So how does gs check? | 14:03.06 |
| kens | It doesn't, it assumes you are giving it correct information | 14:03.16 |
| | THe only way to do it is by inspection | 14:03.49 |
| norbusan | But *where* would I give it this information for a CIDFont/ file? In cidfmap? | 14:03.53 |
| chrisl | norbusan: that's why we have to have that information in the cidfmap | 14:04.00 |
| kens | As Chris says :-) | 14:04.13 |
| norbusan | How do I add an entry for a CIDFont resource in cidfmap? | 14:04.22 |
| chrisl | norbusan: all the entries in cidfmap are CIDFont resource | 14:05.19 |
| kens | Yeah but you can't give CSI information to existing CIDFOnts, because they already contain a CSI dictioanry | 14:05.44 |
| norbusan | Yes, but how does one look that refers to a file in CIDFont? For TTF fonts I can construct an entry | 14:05.45 |
| chrisl | But these aren't CIDFonts, they are OTTO fonts | 14:06.13 |
| norbusan | Ahhh.... | 14:06.22 |
| | So *how* should they be treated? | 14:06.30 |
| kens | I know, but norbusan seems to have got them loaded as CIDFonts, or I misunderstand which is entirely possible | 14:06.35 |
| chrisl | Like TTF | 14:06.38 |
| norbusan | Can they be treated at the momen? | 14:06.39 |
| kens | Treating them just like TTF seems best to me | 14:06.53 |
| norbusan | Yes, we load them from CIDFonts as is | 14:06.54 |
| | kens, chrisl, I will try that and see if that works out. | 14:07.08 |
| kens | We are suggesting you shouldn't do that, I think :-) | 14:07.13 |
| norbusan | In this case it would be much easier for us! | 14:07.15 |
| | Yeah, that was for OTF with TTF outlines, but then you mentioned that OTF/CFF might be different ... | 14:07.52 |
| | Anyway, don't worry! | 14:08.06 |
| | I just do my experiments ;-) | 14:08.11 |
| | If you are interested, I will report back. | 14:08.17 |
| chrisl | norbusan: yes, please do report back.... it would be good to know for sure that the bug I have is not a general problem with OTTO fonts | 14:08.54 |
| norbusan | I try to treat them *exactly* like ttf fonts, including the generation of entries in the cidfmap with \TTFFont as type. I am not sure if that works, but will report. | 14:09.35 |
| chrisl | Yeh, I get an invalid font, if I try that - which is what I expected :-( | 14:12.17 |
| norbusan | aaahhh so not good. | 14:12.36 |
| chrisl | I also cannot get Ghostscript to load an OTTO font directly as a CIDFont..... | 14:13.04 |
| norbusan | Can you take a look at the Resource.tar.gz and try the composition via the font snippet I provided? | 14:14.05 |
| | That should work/ | 14:14.09 |
| chrisl | I cannot, because I don't have those fonts available | 14:14.25 |
| norbusan | chrisl ... I send you one ... | 14:14.36 |
| | sent, not send | 14:14.43 |
| chrisl | Yes, so that worked, but it had the extra entry in the Font directory with the composed name | 14:16.43 |
| | Oh, maybe.... hang on | 14:17.35 |
| | norbusan: okay, the one you sent earlier (YuGo-Bold) does load successfully as a CIDFont, but another OTTO I have locally does not, but does load as a Font resource. Which suggests that the former has a full CFF CIDFont in it, whilst the latter does not. | 14:22.36 |
| | I didn't actually realise you could put a CFF CIDFont in an OTTO font...... | 14:23.15 |
| norbusan | But for this font the auto-composition does not work either, I believe. | 14:23.15 |
| | ;-) | 14:23.29 |
| chrisl | You are correct <baffled>...... | 14:24.34 |
| norbusan | Long hours of experimentation ;-) And lots of work by others ... | 14:25.48 |
| | Bottom line for me for now is: keep everything as it is, only move the ttf fonts into CIDFSubst and adjust the cidfmap lines for the TTF fonts. Keep the pre-generated font snippets in Font/. | 14:27.13 |
| chrisl | And I know why :-( | 14:27.31 |
| norbusan | ?? Wow, that was quick ... | 14:27.49 |
| chrisl | We try to parse out the registry and ordering without actually loading the entire CIDFont (which can be ver time consuming), but the code that does that, doesn't understand OTTO fonts, and probably doesn't understand CFF fonts either | 14:28.54 |
| norbusan | I guess that is a long term project :-( | 14:30.13 |
| chrisl | I suspect that the only way to handle it would be to actually load the CFF CIDFont - but it won't be a quick fix, no.... ;-( | 14:31.23 |
| norbusan | And with fonts growing this can actually be a big pain. What about allowing to define a CID OTTO font in cidfmap? ANyway, I guess you know better what to do. | 14:32.08 |
| | Everyone, thanks for the nice chat, I have to teach tomorrow morning (in Japanese), so I need some good rest before trying to squeeze analysis into students ...Good night! | 14:33.26 |
| chrisl | Allowing OTTO fonts in the cidfmap is also non-trivial, since we currently load OTTO fonts as Postscript Type 2, which means thay don't contain the TTF tables we require to do the subsitution :-( | 14:33.45 |
| norbusan | Ok, I stay with pre-generated font snippets, that work. | 14:34.33 |
| chrisl | What a mess :-( | 14:34.57 |
| | So, our "auto-composing" will only work with CIDFontType 0 (and maybe 1) CIDFonts.... | 14:36.27 |
| kens | Hmm, not so great | 14:36.42 |
| chrisl | I guess it might work with CIDFontType 2 - so I suppose that's not horrid | 14:37.25 |
| | So, who knew you could have a CFF CIDFont in an OTTO file.........? | 14:39.19 |
| kens | I htink I may actually have seen that somewhere | 14:39.37 |
| | But not really thought about it | 14:39.44 |
| chrisl | There seems to be no easy way to tell, either | 14:40.15 |
| Robin_Watts | Idea for the sunday of the show: http://www.computerhistory.org/visit/ ? | 14:40.41 |
| | s/show/meeting/ | 14:40.52 |
| chrisl | Robin_Watts: Will it be open? We looked at it once before..... | 14:41.25 |
| Robin_Watts | Sunday 10-5 | 14:41.33 |
| kens | I htnk it was closed Sunday when we looked | 14:41.34 |
| | OK that's changed then | 14:41.40 |
| chrisl | No, it's closed Monday/Tuesday - it was probably a Monday last time we tried | 14:42.08 |
| kens | Hmm, need to drive ? | 14:42.09 |
| Robin_Watts | It's far enough that we can't walk. | 14:42.21 |
| kens | 2 iles it says | 14:42.29 |
| | miles* | 14:42.33 |
| Robin_Watts | I don't believe it's 2 miles :) | 14:42.43 |
| kens | Well I'm going by the web site | 14:42.57 |
| | WHich also says there's a community shuttle | 14:43.04 |
| Robin_Watts | My running route (6+ miles) only goes about halfway there. | 14:43.09 |
| kens | 2 miles from Mountian View CalTrans | 14:43.23 |
| | CalTrain, cannot type.... | 14:43.38 |
| | Car would be easier though | 14:43.44 |
| Robin_Watts | https://www.google.co.uk/maps/dir/Hilton+San+Francisco+Airport+Bayfront,+600+Airport+Boulevard,+Burlingame,+CA+94010,+United+States/Computer+History+Museum,+1401+North+Shoreline+Boulevard,+Mountain+View,+CA+94043,+United+States/@37.5020204,-122.284043,12z/data=!3m2!4b1!5s0x808fb75692370241:0x72ed99a2ec7d5fd6!4m14!4m13!1m5!1m1!1s0x808f9d8df6f450ab:0xdd58d47a4a270c62!2m2!1d-122.343348!2d37.589502!1m | 14:43.47 |
| | 5!1m1!1s0x808fb7569249b39b:0xea8071641d7ef4f2!2m2!1d-122.077409!2d37.414274!3e2 | 14:43.49 |
| | 21.2 miles. | 14:43.56 |
| kens | Yeah, like I sai, 2 miles from trhe station | 14:44.10 |
| chrisl | Oh, I thought that was a *really* long swear word....... | 14:44.13 |
| Robin_Watts | oh, I see. | 14:44.28 |
| chrisl | I'd certainly be up for it, if we can sort out transportation | 14:44.45 |
| Robin_Watts | I think a cab would be smartest given there will be at least 4 of us. | 14:44.47 |
| kens | cab sounds best yes | 14:45.03 |
| Robin_Watts | It's a straight shot down the 101. | 14:45.09 |
| | actually... we may need 2 cabs, cos Joseph/Pete/Tor/Chris/Ken/Paul/Me makes 7... | 14:45.54 |
| | or an Uber XL. | 14:46.22 |
| kens | Pete and Joseph coming too ths time ? | 14:46.24 |
| | Tor won't be there | 14:46.37 |
| Robin_Watts | I believe so. | 14:46.40 |
| kens | Last I heard | 14:46.43 |
| Robin_Watts | oh, right. 6 in a car may be doable. | 14:46.52 |
| | I'd forgotten our torlessness. | 14:47.03 |
| kens | Be good to see Pete and Joseph again | 14:47.10 |
| Robin_Watts | Matt (who did some work for us) may also be there; he is going to WWDC, but doesn't know when he is flying in yet. | 14:47.54 |
| kens | More the merrier | 14:48.16 |
| | Anyway, count me in | 14:48.25 |
| kens | will wear TNMOC T-shirt | 14:48.49 |
| henrys | we could have this field trip instead of the technical meeting, it's technical right? | 14:49.14 |
| kens | But then what would we do on Sunday ? | 14:49.37 |
| chrisl | We could say we want to port mupdf to the Altair :-) | 14:49.59 |
| Robin_Watts | henrys: It's open saturday too (10-5). so it depends how long the saturday meeting is) | 14:50.18 |
| | There is a "Women in Computing" tour, but it only runs once a month. | 14:51.08 |
| | I can't help feeling they have that proportion slightly too high there :) | 14:51.20 |
| chrisl | It does seem slightly patronising to have it on a monthly cycle...... | 14:51.56 |
| Robin_Watts | chrisl: haha | 14:52.33 |
| rayjj | I wonder if my buddy that I worked with at the University still has his Altair. I soldered most of it for him (he had never soldered before and realized he needed help after melting some of the plastic on the chip sockets) | 16:35.40 |
| chrisl | rayjj: if it still works, it's worth a chunk of money these days..... | 16:36.37 |
| rayjj | I recall loading (using the front panel switches) in the opening of Tocatta and Fugue in D minor to play on an adjacent AM radio | 16:37.23 |
| chrisl | I saw a similar demo when I was at university - not on an Altair, though | 16:38.24 |
| rayjj | I wonder if there are any pictures of my dad at the museum. A picture of him next to one of the IBM computers was on page 6 of my sister's "Intro to Computers" textbook :-) | 16:40.00 |
| mvrhel_laptop | fredross-perry: I fixed the page count issue you showed me. thanks | 23:04.10 |
| fredross-perry | good deal | 23:04.21 |
| | that turned out to be the source of my issues with epub in general | 23:04.46 |
| Robin_Watts | mvrhel_laptop: So is epub behaving for you too now ? | 23:09.16 |
| mvrhel_laptop | yes it is all fixed now | 23:09.33 |
| | An updated gsview for windows is in ~mvrhel/gsview | 23:09.56 |
| Robin_Watts | Yeah, I'm buried in google docs hell at the moment, but I want to give it a whirl. | 23:10.15 |
| mvrhel_laptop | no problem | 23:10.21 |
| | I have been beating on it and found a few more bugs that I just fixed | 23:10.34 |
| | need to let it loose soon. I have a pile of customer bugs in my queue | 23:10.52 |
| rayjj | mvrhel: (for the logs) I've added code to the PDF interpreter to (hopefully) handle the section 7.6.4 transfer function better. Also I fixed TRDefault to work with separate transfer function for CMYK (RGB+Gray). Running a cluster test to see what blows up. | 23:44.41 |
| | This is related to bug 695904 and _does_ change the center non-opaque square, as expected | 23:46.18 |
| | mvrhel_laptop: check the logs from a few minutes ago | 23:52.46 |
| | Forward 1 day (to 2015/04/21)>>> | |
IRC Logs