| | <<<Back 1 day (to 2015/01/27) | 20150128 |
| Curs0r | Hello all. I wonder if anyone could point me in the right direction on something. I have a string being fed into postscript. It contains accented characters. When they get written out to a pdf via ghostscript in a shell script they don't render right. I looked at this and followed its instructions http://apps.jcns.fz-juelich.de/doku/sc/ps-latin but they're still doing it. I'm not sure what to do next | 10:04.01 |
| kens | You probably don;t have the font you are using correctly encoded. Instead of writing a PDF< try rendering to the display, if the glyphs are incorrect when rendered then they will be incorrect in a PDF file. | 10:04.51 |
| | The article is incorrect that PostScript fonts are encoded to 7-bit ASCII, they use the full 8 bits, but they may not map to some other encoding. Generally fonts use StandardEncoding, whch is defined in the PostScript Language Reference Manual. | 10:07.31 |
| | Wihtout seeing the PostScript program you are using there's no other help I can offer. Also, I'm about to go out for a couple of hours. If you want to post a link to your program I can take a look at it this afternoon. | 10:08.52 |
| Curs0r | pastebin.com/x4LVdTdP There is what I'm using. Pretty much verbatim from that article | 10:15.21 |
| Robin_Watts | Most of you have met Scotts sister Kelly, I think. | 12:52.58 |
| | Her husband is in for a heart operation today (11am their time). Needs a stent etc. | 12:53.27 |
| kens | Curs0r : your PostScript seems to work for me, it renders ${TEXT} quite well. | 13:47.16 |
| | However, that's not a great way to re-encode a font, apart from anything else its leaving a dicitonary on the operand stack | 13:47.42 |
| | Curs0r : I also just tried replacing ${TEXT} with \300\301\302 and I get capital A acute, capital A grave and cpaital A circumflex. So as far as I can tell, everything works just fine. You're going to have tp provide a genuine example. | 14:13.33 |
| | Morning rayjj | 14:31.23 |
| henrys | was asking for a break yesterday, it came... If I take the courier from adobe acrobat cff and plug it into pcl, remove the check for the first 4 bytes being TT magic it just works. The way freetype is set up it doesn't seem to matter ... | 14:35.47 |
| | cff fonts are interchangeble with the TT's | 14:37.23 |
| kens | That's nice, I thought it should be easy enough to add CFF fonts | 14:37.45 |
| henrys | adobe's courier is quite different but that shouldn't be an issue when we get the URW cff's | 14:39.15 |
| kens | I presume URWs CFF outlines will match the type 1s, and will be at least reasonably similar to the TT ones. | 14:39.43 |
| | I wonder if they got the metrics the same though | 14:40.03 |
| | THa'ts probably going to be important to PCL | 14:40.14 |
| | Well,the widths anyway | 14:40.34 |
| henrys | it is and that is part of the reason for my not wanting to change but we'll deal with it I guess... | 14:40.54 |
| kens | But we have to change either GS or PCL if we want one set of fonts for all, and the same problem applies in PostScript, its just less of an issue. But its still possible to write '(ABCD) show' and it will rely on the widths being the same as the PostScript widths | 14:42.03 |
| | In fact if the TT widths and PostScript widths don't match we are going to have a problem anyway. GS needs the PS widths to match Adobe. I'm not sure what PCL has to match, but presumably something | 14:42.38 |
| | I sincerely hope the widths are going to be the same | 14:42.49 |
| henrys | we might have to separate width data for PCL we can check right now. | 14:46.59 |
| kens | Umm, I guess that would work, if we track teh current point before showing a glyph and then update it after. THat would be tricky to do in GS | 14:47.33 |
| | THough I suppose we could do that in the FAPI FreeType layer | 14:47.53 |
| | It would probably be easier in PCL, I assume that if we see a CFF font we can be sure its one of our 'built in' fonts, because there's no way to get a CFF into PCL otehrwise | 14:48.43 |
| | Or does PCLXL support OpenType ? | 14:49.00 |
| henrys | the terminology is confusing... openttype is TT that can have extra tables and support postscript outlines. Change the first 4 bytes of the tt font and it's OpenType. | 14:50.51 |
| kens | Well, if it supports OpenType fully it needs to support both TT outlines and CFF outlines. | 14:51.20 |
| | Otherwise it doesn't really support OpenType | 14:51.29 |
| | Its like the difference between versions in the header of a binary file like PDF | 14:51.52 |
| henrys | PCL knows nothing about CFF | 14:52.13 |
| kens | OK then it doesn't support OpenType | 14:52.24 |
| | In effect it supports 'version 1' | 14:52.31 |
| | But not 'version 2' | 14:52.35 |
| | So if we see a CFF outline, then we know we put it there ourselves, it cna't be a downloaded font | 14:52.59 |
| henrys | neither does PDF - it doesn't support every single table so it doesn't support open type with your reasoning. | 14:53.09 |
| kens | Which tables does PDF not support ? | 14:53.28 |
| | Note that fonts need not contain all tables anyway | 14:53.44 |
| | And PDF doesn't need a lot of the table, because it doesn't need a lot of the metric info | 14:54.22 |
| | I can support version 2 of a specification without using all the information in it, if I don't need that information. But if I do need the information, and don't support it, then I can't say that I support version 2 of the spec | 14:55.13 |
| | The outlines of the glyphs aren't something I can reasonably ignore | 14:55.48 |
| | I cna't see anything in the PDF spec that says it doesn't support certain TrueType tables | 14:57.46 |
| | It does say that the VHEA and VMTX tables aren't used, but that's because PDF has irts own wqay to specify those | 14:58.42 |
| henrys | I stopped arguing ;-) | 14:59.05 |
| | pcl does not support opentype and pdf does ... got it. | 15:00.32 |
| kens | I'm merely trying to figure out if the fact that we have a CFF outline is a usable guide to overriding the widths, in PCL> I wouldn't be in PostScript or PDF. | 15:01.28 |
| | Should we need to override widths that is | 15:01.54 |
| henrys | the way gridfitting works in truetype - the ft code renders the glyph to get the actual width as I see it working now. It used to pull the width from the font data. | 15:03.57 |
| kens | Hmm, don't remember, sorry. Have to ask chrisl about that one and he's on vacation today | 15:04.25 |
| henrys | right | 15:04.39 |
| kens | I thought the advance width (not the glyph bbox) was given in the HMTX | 15:04.43 |
| | Its possible that it uses the glyph bbox for the rid fitting, but not for the advance | 15:05.10 |
| | *grid | 15:05.16 |
| henrys | I'll look at it again today. Looked like it was fully rendering the glyph to me and not trusting the font data. | 15:05.57 |
| | but I'm not positive | 15:06.04 |
| kens | Thinking about it, I wonder what happens if you specify an OTF font with CFF otulines, where the HMTX don't match the widths in the CFF | 15:06.07 |
| | I suspect that would be regarded as a botched font design :-) | 15:06.34 |
| henrys | bad day for chris to have a vacation this stuff just got hot last night. Oh well, we'll muddle through | 15:08.00 |
| | good thing it's just 1 day. | 15:08.09 |
| kens | I can put this aside if you want me to take a look, I won;t be as fast as chris though | 15:08.21 |
| | Do we actually have someone interested in a language switching build ? | 15:09.05 |
| henrys | rayjj will probably end up talking to them but we need to estimate what the cff 136 font load will be so we can come up with a rom size for gs. I was really hoping for a cff delivery from urw today but it isn't here yet. | 15:10.27 |
| Robin_Watts | henrys: If only we had some code to force the metrics on fonts to be what we want... | 15:10.45 |
| kens | One in CFF format ? Otherwise we'll have to convert it to find the size, which will take a little longer. | 15:10.56 |
| | Robin_Watts : we may need the metrics to be different for PS and PCL | 15:11.14 |
| | WHich was one of the reasons I was wondering about having different HMTX tables in a OTF font with CFF outlines, different to the CFF widths that is | 15:12.33 |
| Robin_Watts | kens: ef1 = truetype with some tables stripped out. | 15:12.55 |
| henrys | kens: well I think just converting fonts may not be an accurate estimate to what their tool actually generates. It might be close. | 15:13.02 |
| Robin_Watts | otf = ttf with some extra tables. | 15:13.06 |
| | so the code we have to force metrics is designed to work on ttfs. | 15:13.22 |
| kens | henrys if they don't supply us with CFF fonts it'll be 'similar' but clearly not the same no. WOuld be a good estimate though | 15:13.25 |
| henrys | Robin_Watts: don't tell ken that ;-) | 15:13.26 |
| kens | OTF is not the same as TTF with extra tbales, teh glyph outline data can be quite different | 15:13.45 |
| Robin_Watts | As long as the htmx and kerning tables are the same in otf and ttf, then our metrics forcing code will work. | 15:13.47 |
| | kens: metrics forcing doesn't care about the glyph outlines. | 15:14.03 |
| kens | Robin_Watts : I'm really thinking about the case of the PCL and PS interpreters. | 15:14.03 |
| | Robin_Watts : the widths used by the PS interpreter for a OTF font with CFF outlines will be the widths in the CFF outlines. | 15:14.39 |
| | Which clearly ought to be the same as the metrics given in the HMTX tables, but may not be | 15:15.02 |
| | I'[m wondering what happens if they are not. | 15:15.10 |
| henrys | Robin_Watts: I don't think forcing metrics will work, I do wish chrisl_away were here but it looks to me like we are not trusting the metrics, rendering and grabbing the bbox. but I only stepped through it a bit I'll look more today. | 15:15.33 |
| Robin_Watts | kens: That surprises me, but I'm not in a position to argue authoratively. | 15:15.33 |
| kens | Specifically for the case of the PCL and PS interpreters. We could use the HMTX for PCL and the CFF widths for PS and that way get both sets of metrics in one font | 15:15.47 |
| Robin_Watts | I mean, consider a row of 'I' glyphs. | 15:16.00 |
| | The glyphs don't exactly abut one another. | 15:16.21 |
| kens | Robin_Watts : I understand metric..... | 15:16.32 |
| Robin_Watts | So unless the CFF 'outlines' aren't just 'outlines' but are 'outlines, plus advance' I don't see how the outlines matter. | 15:16.54 |
| kens | CFF outline data includes the advance widht for the glyph, yes. | 15:17.11 |
| Robin_Watts | kens: Right. | 15:17.29 |
| kens | Because a CFF font need not be embedded in a OTF | 15:17.30 |
| | So we have two sources of metrics in a OTF font with CFF toulines | 15:17.44 |
| Robin_Watts | So we could update the CFF outlines as part of the metric forcing if we wanted to. | 15:17.47 |
| kens | We could, yes, but that's not what I was thinking | 15:17.58 |
| | We almost certainly don;t want to do that | 15:18.08 |
| | Because the PostScript metrics in the CFF font will be what we want for GS. But for PCL, the CFF advance may not be what's needed to match whatever font set we compare against for PCL. | 15:18.42 |
| | In which case we would need to do metric adjustment. I was just wondering if we could get that whole set of information in one font package by bending the HMTX in the OTF font with CFF toulines. THen we could use the HMTX for PCL and teh CFF advance for PostScript | 15:19.30 |
| henrys | kens: what do you use to convert Type 1 to CFF. We have to look at the newly delivered files with expanded glyph sets. | 15:21.09 |
| | ? | 15:21.16 |
| kens | There is code in pdfwrite to convert Type 1 to CFF | 15:21.23 |
| | I don't have a stand-alone executable to do it, but I could write one | 15:21.43 |
| | Or just run some PS thourgh GS to pdfwrite with font subsetting disabled :-) | 15:22.04 |
| henrys | I did it in fontforge converting one of the PCL TT's to CFF but it was very bloated against the original. | 15:22.32 |
| kens | Well converting TTF to CFF is likely to have that effect. | 15:22.51 |
| | Doing the same with a type 1 starter should not have that effect | 15:23.05 |
| | If you have fontforge there, its probably easiest to use that. | 15:23.26 |
| henrys | I'll try one of the new type1's and see what I get. | 15:23.37 |
| kens | IIRC you shoudl see ~30% reduction in CFF over type 1 | 15:23.38 |
| Robin_Watts | kens: convert TTF to Type 1, then convert Type 1 to CFF? That would get the bloat over in the first phase, and the second phase would tell you what you want? | 15:23.47 |
| kens | Robin_Watts : I don;t think we ned to worry about TTF here. | 15:24.20 |
| | AIUI that just happened to be what Henry was testing with before | 15:24.40 |
| | If we absolutely need a stand-alone type 1 to CFF parser I'll pull the code out of pdfwrite and make one | 15:25.06 |
| henrys | right we want an estimate for gs footprint with the new fonts (136) in cff | 15:25.08 |
| kens | SO I would do as you say, try a single type 1 with FontForge and see if ti comes out smaller (it should) | 15:25.30 |
| | If it does then you can do all the fonts and get a reasnable estimate of the size when all the fonts are converted. | 15:25.49 |
| henrys | they want pcl footprint too but I'll jump off that cliff in a minute | 15:25.50 |
| kens | Hmm, so they want footprints for GS on its own and PCL on its own ? And teh 2 combined as well ? | 15:26.28 |
| henrys | Here are the words: | 15:28.05 |
| | Can I get required ROM & RAM size? | 15:28.10 |
| | PCL5/6 + URW font data | 15:28.10 |
| | PS/PDF + URW font data | 15:28.11 |
| kens | Hm, well fair enough seems like they want the two as stand-alone | 15:28.55 |
| henrys | sure but does this person understand that and will engineering see a better way of sharing stuff... so we need to be prepared to have numbers for this configuration but also shared. | 15:30.37 |
| kens | Indeed, sooner or later someone will want a combined setup.... | 15:31.07 |
| | I've long thought we should do something about a decent language_swtich build. One that actually works. | 15:31.40 |
| henrys | great the 3 pfb font families range in size from 40K to 80K making extrapolating to 136 size likely wrong | 15:32.46 |
| kens | Hmm, look a the percentage decrease for one font. Add up all the fonts, decrease the total size by that percentage | 15:33.23 |
| | It won't be correct but the alternative is to convert all the fonts, which would be tedious | 15:33.40 |
| | Oh, you don't have the fulll 136 fonts available ? | 15:34.02 |
| henrys | kens: I don't have the fonts, we need to measure the complete 136 with glyph extensions | 15:34.14 |
| kens | Do we know the size of the full 136 font set ? | 15:34.42 |
| | If not, there's no realistic way to do this | 15:34.52 |
| | Font sizes vary dramatically I'm afraid | 15:35.03 |
| tor8 | henrys: kens: you can batch script fontforge to do multiple conversions at once | 15:37.21 |
| | http://pastebin.com/Byd8G1Dc | 15:37.23 |
| kens | tor8 yeah but if we don't have the fonts..... | 15:37.38 |
| tor8 | kens: to get an estimate of type1-to-cff for the 136 set | 15:38.00 |
| Robin_Watts | We have the 136 set in what format? | 15:38.15 |
| kens | I don't think we have it at all do we ? I thought that was what Henry said | 15:38.27 |
| | They haven't delivered it yet | 15:38.32 |
| Robin_Watts | ah, I see. | 15:38.39 |
| henrys | tor8: I was hoping these 3 fonts would be of similar size. I have no idea what the rest of the fonts will look like, I could go with the max of these 3 as a safe number. | 15:39.00 |
| | well not that safe but safer than a smaller one ;-) | 15:39.24 |
| | thanks for the script tor8 | 15:39.40 |
| kens | IIRC latin type 1 fonts run t ~60Kb on average | 15:39.41 |
| | But of course, additional glyphs will make them larger | 15:39.54 |
| henrys | tor8: does fontforge have a variable for filename not fontname? | 15:50.30 |
| | a quick glance is 50% | 15:50.47 |
| tor8 | henrys: http://fontforge.github.io/en-US/documentation/scripting/native/ | 15:55.38 |
| | henrys: $filename | 15:56.04 |
| henrys | tor8: what's with your cat ^D shenanigans ? It made emacs shell mad. ;-) | 15:57.09 |
| | tor8: oh and I assume you are okay with the move to cff for gs and pcl don't have any concerns etc.? | 15:59.01 |
| | Robin_Watts: I wonder how much of the table stripping used in SOT could be applied to the CFF's. | 16:04.11 |
| kens | CFFs don't have tables like TTFs | 16:04.26 |
| | You need all the stuff that's in a CFF font | 16:04.34 |
| | Well, you could reduce the copyright notice, but font vendors tend to frown on that | 16:04.49 |
| Robin_Watts | kens: is that true of otfs with cff outlines ? | 16:05.19 |
| kens | No, just CFF fonts | 16:05.28 |
| Robin_Watts | Right, so the SOT table stripping might apply to otfs made from the CFFs, if not to the CFFs themselves. | 16:05.58 |
| kens | An OTF font with CFF outlines will have a bunch of tables, which GS at least doesn't need | 16:06.03 |
| | TBH I'd rather bundle the fonts as bare CFF, they'll be at their smallest that way | 16:07.03 |
| Robin_Watts | kens: but that's no good for pcl, I thought. | 16:07.32 |
| kens | As teh PCL interpreter currently stands, perhaps not | 16:07.51 |
| | But there's no reason why we couldn't change that. | 16:08.00 |
| | After all,Henry was proposing we change the PostScript interpreter so that it handled TrueType fonts (which PostScript interpreters don't do) | 16:08.25 |
| | I shoudl say changed the built-in fonts to TTF | 16:09.02 |
| | And its true that PostScript handles type 42 which is not entirely unlike a TTF, and GS has extensions to load TTFs, which amazingly work, mostly. | 16:09.34 |
| henrys | kens: is there something in the postscript spec that says it should only work with Type1 or 2 I never found it. | 16:09.34 |
| kens | Henrys, thespec tells you which font types are supported, TrueType is not one of them | 16:09.57 |
| | PS (level 3) works with type 0, type 1, CFF, type 3, TYpe 42, and CIDFonts of any of the preceding types | 16:10.36 |
| | THere are proprietary extensions (type 99) and also Multiple Masters. | 16:10.54 |
| henrys | we've built gs with a complete set of type 42's and it works for most files. | 16:11.08 |
| kens | While type 42 fonts are (basically) TrueType fonts, TrueType fonts are not supported | 16:11.13 |
| henrys | sorry truetype not type 42 | 16:11.27 |
| kens | henrys I don;t think we've built it with Type 42 fonts. More likely TrueType, which is not quite the same thing | 16:11.35 |
| | henrys, in general our TTF support works, but sadly 'in general' isn't good enough, certainly not for the built-in fonts. | 16:12.00 |
| | When someone complains that their use of a TTF doesn't work we can say 'ah, the spec doesn't allow for TTF, that's an extension, and so not guraranteed' | 16:12.36 |
| henrys | urw is going to deliver otf with cff outlines. | 16:12.39 |
| kens | THat isn't reallly a defensible position for the built-in fonts | 16:12.46 |
| henrys | my position is TT should work for the built in fonts but I'm not arguing that one. It has to work for the UFST, that's not really debatable | 16:14.59 |
| kens | Henrys there's no real prospect of getting away with using TTF for the built-in fonts. | 16:15.20 |
| | As we've said we have example files which fail in unfixable ways when a TTF is used. If that's oe of our built-in fonts, we are knackered | 16:15.48 |
| | If a customer insists on using UFST with PostScript and it fails then we cna say 'hassle UFST' | 16:16.28 |
| | err Monotype | 16:16.34 |
| henrys | I think if we can get away with not changing PCL at otf with cff outlines has to be considered if it isn't much bulkier. We'll see what they deliver. | 16:19.32 |
| kens | Well OTF with CFF has to be smaller than type 1 | 16:19.52 |
| | If you really need to know its fairly easy to pull the CFF out and see how much overhead the OTF tables are causing | 16:20.23 |
| mvrhel_laptop | good morning | 16:21.44 |
| Robin_Watts | mvrhel_laptop: Morning. | 16:22.06 |
| mvrhel_laptop | Robin_Watts: thanks for looking over the commits | 16:22.22 |
| kens | Monring mvrhel_laptop | 16:22.24 |
| Robin_Watts | mvrhel_laptop: no worries. | 16:22.30 |
| mvrhel_laptop | I have a minor commit on my mupdf repos too when you get a chance | 16:22.53 |
| Robin_Watts | mvrhel_laptop: Can't argue with them. lgtm. | 16:23.50 |
| mvrhel_laptop | ok thanks | 16:24.04 |
| | been testing out gsview on various systems around here with mixed results. the registry changes for updating the open with is not working on one machine for some odd reason. hope to get that figured out today | 16:24.14 |
| rayjj | mvrhel_laptop: I noticed that you are now using nsis -- does it work OK for you ? | 16:25.25 |
| | or is that the cause of the "open with" not working | 16:25.59 |
| mvrhel_laptop | rayjj: it is working very well | 16:26.34 |
| | it has gotten me to testing on other machines etc | 16:27.06 |
| | I suspect that this issue is something particular about windows 8 | 16:27.24 |
| rayjj | henrys: for estimating ROM and RAM size we _should_ know which CPU (x86 is different to ARM or other RISC) and RAM estimates for 'diskless' means clist | 16:27.31 |
| mvrhel_laptop | and how the tile apps are populating the open with in a different way | 16:27.39 |
| | the registry commands on this particular machine just don't seem to be doing anything for the pdf and xps extension settings. no error returns from the commands either. but I have an idea to try today | 16:28.34 |
| rayjj | henrys: so for diskless that includes clist, IMHO we should give both with and without compression | 16:29.06 |
| henrys | rayjj yup I suspect you'll be guiding them down that righteous path soon... asking all the questions and such. | 16:30.28 |
| rayjj | henrys: and for clist size, we need to pick a "well known" suite of files such as JEITA, QL FTS, QL ATS, or whatever. I can go ahead an collect clist sizes for the 'standard' suites we have, since that doesn't change for CPU type | 16:32.13 |
| henrys | I'll send you the company in email probably best to have a browse at their printers now... | 16:32.50 |
| rayjj | henrys: do we know if it is diskless (I guessed that it probably was if they are concerned about ROM size) | 16:32.50 |
| | henrys: OK. Thanks | 16:33.05 |
| henrys | rayjj: okay sent | 16:39.48 |
| | bbiam | 16:40.05 |
| rayjj | does anyone want to look at my commit for a trivial pattern_size_estimate fix (only affects devices that use tags) | 16:40.59 |
| kens | Not hugely, I can't believe I'd have any useful input | 16:41.32 |
| rayjj | if so, it's at: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=3041c9d716860b71dcca580990c8f421dc002ece | 16:41.57 |
| | kens: well you could see if my log message makes sense :-) | 16:42.13 |
| kens | 'is and int' ? BUt as I suspected, not really got any ideas. | 16:42.52 |
| rayjj | kens: oh, thanks, s/b "is an int" | 16:43.23 |
| kens | I suspected so, its pretty trivial | 16:43.36 |
| | I've no idea if the code makes sense though :-) | 16:44.02 |
| Robin_Watts | rayjj: seems sane to me too. | 16:45.26 |
| rayjj | Robin_Watts: thanks. At least it's closer to making sense now (at least to me) | 16:49.49 |
| henrys | rayjj: I may be picky today but doesn't that warrant a code comment. | 16:49.59 |
| rayjj | henrys: OK, I'll add one: /* if we have tags, add the extra byte */ -- sound OK ? | 16:51.04 |
| Robin_Watts | Possibly we could just do: has_tags = !!has_tags; /* Sanitise the bool */ | 16:52.00 |
| henrys | something to remind the reader that has_tags has value other than true and false, is what bothers me reading. | 16:52.03 |
| rayjj | it sort of assumes that the reader knows that the pdf14 compositor keeps tags separate and it isn't included in 'depth' | 16:52.11 |
| henrys | the name has_tags says 0 or 1 to me. that's all . | 16:52.39 |
| Robin_Watts | henrys: Yeah, I'd suggest that the caller of this function is doing a bad thing, | 16:52.58 |
| rayjj | henrys: 'false' can be any non-zero value | 16:52.59 |
| Robin_Watts | rayjj: true? :) | 16:53.10 |
| rayjj | Robin_Watts: yes, I meant 'true' sorry | 16:53.36 |
| Robin_Watts | But sanitising the bool (i.e. forcing it to be 0 or 1) seems a neat thing to do. | 16:53.44 |
| henrys | yeah that would solve my reading issue. | 16:54.38 |
| rayjj | I don't know the C spec, does: int has_tags = (tdev->graphics_type_tag & GS_DEVICE_ENCODES_TAGS) != 0; result in value == 1 ? | 16:55.29 |
| | or is it just guarantee a non-zero value | 16:56.25 |
| Robin_Watts | x != 0 is guaranteed to be 0 or 1. | 16:57.05 |
| henrys | looks to me like the parameter should be named "tag" then locally have bool have_tag = tag != 0 ... then I wouldn't need a comment. | 16:58.09 |
| rayjj | I'll go ahead and clean up the code to pass it around as 'bool' (which is really still an 'int') and make the code use it properly | 16:58.22 |
| henrys | rayjj: that's fine too. | 16:58.36 |
| Robin_Watts | !! is a useful trick. It takes any int to a bool, effectively. | 16:59.07 |
| henrys | I hate to bring this up but should we have a tag testing device in the cluster? | 17:02.29 |
| rayjj | henrys: we have bittagrgb | 17:02.49 |
| henrys | ah I probably knew that once .... | 17:03.44 |
| rayjj | actually it is 'bitrgbtags' I couldn't recall, but it doesn't look like it's in the make files by default. | 17:06.18 |
| henrys | rayjj: I know we have the device, I was asking about the cluster. | 17:07.03 |
| rayjj | henrys: should we add it into the default set so that the weekly that tests all devices will pick it up ? | 17:07.04 |
| henrys | sure | 17:07.25 |
| rayjj | henrys: (and/or Robin), please see if this commit is preferable: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=898ece61f633270c73a7c80d3337783d8a2f0b83 | 17:08.37 |
| Robin_Watts | do we have a bool type? | 17:09.06 |
| rayjj | oops. nm. I didn't fix the commit message. | 17:09.07 |
| | now it doesn't match the code | 17:09.25 |
| Robin_Watts | bool is not a C standard type. My dodgy memory tells me that gs doesn't define it. | 17:10.23 |
| rayjj | Robin_Watts: yes, in stdpre.h, following the comment: Define a Boolean type. | 17:10.47 |
| Robin_Watts | OK. crap memory is crap then :) | 17:10.57 |
| | Then that looks great. | 17:11.04 |
| rayjj | it's either an 'int' or an unsigned char | 17:11.11 |
| Robin_Watts | urk. | 17:11.23 |
| | really? | 17:11.25 |
| | to have it vary between types on different platforms is asking for trouble. | 17:11.43 |
| henrys | rayjj: lgtm | 17:13.20 |
| rayjj | Robin_Watts: agreed, but "BEOS" is pretty well gone, afaik. I don't know why it was the only one that was unsigned char | 17:14.11 |
| henrys | rayjj: see your email | 17:51.40 |
| rayjj | henrys: I read the thread and will collect initial data on ROM/RAM for the code with the amount for the fonts identified so that when new font data is available, we can just plug that in. | 18:21.18 |
| | henrys: note that the fonts are currently NOT compressed in the %rom% area since the .pfb's (with eexec obfuscation) don't compress | 18:22.56 |
| henrys | rayjj: okay | 19:15.27 |
| | wow this support is a tough job ;-) | 19:44.12 |
| | Forward 1 day (to 2015/01/29)>>> | |
IRC Logs