Re: Unicode Core
Asmus wrote: The Unicode Standard easily uses hundreds of fonts for the code charts, from a variety of sources. Despite what should theoretically work, not all systems can actually print every code chart. Some users cannot print certain of the existing PDFs on their systems, and POD providers have similar issues. The Unicode code charts provide a very nice stress test for some aspects of rendering, it turns out. So, as long as code charts create production issues, print-on-demand for them is effectively not feasible. My hard-copy of the code charts was printed by Lulu - they're too big to print out on my office laserprinters! The only issue was joining together the fonts that had been split up when the charts were split into separate PDFs; but the Consortium wouldn't have that problem, as it would just generate the entire PDF as one document. (And unlike me, the Consortium probably has Distiller.) The standard annexes exist in HTML format. For Unicode 5.0, I took the That's more of an issue - I hadn't realized the annexes were actually composed in HTML - I'd assumed they were written in a high-level markup language and the HTML generated. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Unicode Core
On 6/21/2012 11:22 PM, Julian Bradfield wrote: So, as long as code charts create production issues, print-on-demand for them is effectively not feasible. My hard-copy of the code charts was printed by Lulu - they're too big to print out on my office laserprinters! The only issue was joining together the fonts that had been split up when the charts were split into separate PDFs; but the Consortium wouldn't have that problem, as it would just generate the entire PDF as one document. (And unlike me, the Consortium probably has Distiller.) To echo what Michael said here, the editors are looking into this. We did, in fact, do the work to volumize the entire set of charts, including all of CJK, for POD, and even made volume covers and title pages. However, it turned out that Lulu had production issues for at least some of those volumes. So at the last minute we had to limit the POD to just the core specification, which didn't cause printing problems. It was an interesting experiment, and we learned some lessons from it. But we simply do not have the bandwidth to finish wrestling with it for Unicode 6.1 right now. (The Unicode 6.2 beta is underway, and the people involved with charts need to focus on getting Unicode 6.2 charts prepared.) I anticipate that once Unicode 6.2 is done, the editors may take another crack at this, and manage to create volumes for charts with settings that won't make Lulu production printers crash and burn. But all in good time. --Ken
Re: Unicode Core
From: Ken Whistler kenw_at_sybase.com To echo what Michael said here, the editors are looking into this. We did, in fact, do the work to volumize the entire set of charts, including all of CJK, for POD, and even made volume covers and title pages. However, it turned out that Lulu had production issues for at least some of those volumes. So at the last minute we had to limit the POD to just the core specification, which didn't cause printing problems. It was an interesting experiment, and we learned some lessons from it. But we simply do not have the bandwidth to finish wrestling with it for Unicode 6.1 right now. (The Unicode 6.2 beta is underway, and the people involved with charts need to focus on getting Unicode 6.2 charts prepared.) I anticipate that once Unicode 6.2 is done, the editors may take another crack at this, and manage to create volumes for charts with settings that won't make Lulu production printers crash and burn. But all in good time. --Ken Wait a minute. Isn't 6.2 just adding the Turkish Lira? Does that really take the chart people more than about 10 minutes? -Van PS, interesting that you had production issues on doing the code charts as print-on-demand. I guess that's not quite as straightforward a process as you would think.
Re: Unicode Core
vanis...@boil.afraid.org 於 2012年6月22日 下午3:49 寫道： Wait a minute. Isn't 6.2 just adding the Turkish Lira? Does that really take the chart people more than about 10 minutes? The only *character* change is the Turkish lira. There are numerous updates to UAXes and other parts of the documentation. = Hoani H. Tinikini John H. Jenkins jenk...@apple.com
Re: Unicode Core
On 6/22/2012 3:55 PM, John H. Jenkins wrote: Wait a minute. Isn't 6.2 just adding the Turkish Lira? Does that really take the chart people more than about 10 minutes? The only *character* change is the Turkish lira. There are numerous updates to UAXes and other parts of the documentation. And for the chart people the problem is that a non-zero (actually substantial) number of the Han fonts and the glyphs therein have changed, and any time one touches *any* of the Han fonts, it takes more than 10 minutes just to screw up the courage to *start* the chart generation. ;-) The change control for the Han fonts, now that we are generating multi-column charts, based on fonts being provided by multiple different national bodies, verges on nightmarish. --Ken
Re: Unicode Core
On 21 Jun 2012, at 09:47, Raymond Mercier wrote: While I am very glad to have this, I really do wonder why there was not a full publication of Unicode 6 or 6.1 from the corporation itself, with all the charts, as we have had with Unicode 1 to 5. Surely there is a market for this ? Perhaps less than us character mavens would imagine. Books don't publish themselves, and publishing takes resources of various kinds. But I understand that the Powers That Be are looking into the matter. Michael Everson * http://www.evertype.com/
Re: Unicode Core
From: Michael Everson everson_at_evertype.com On 21 Jun 2012, at 09:47, Raymond Mercier wrote: While I am very glad to have this, I really do wonder why there was not a full publication of Unicode 6 or 6.1 from the corporation itself, with all the charts, as we have had with Unicode 1 to 5. Surely there is a market for this ? Perhaps less than us character mavens would imagine. Books don't publish themselves, and publishing takes resources of various kinds. But I understand that the Powers That Be are looking into the matter. Michael Everson * http://www.evertype.com/ Not to mention, it would be freaking HUGE! The Core specification is published at 600+ pages, code charts are another 2000+, and all the UAXs, Radical-Stroke indices, etc would push it to well over 3k pages. Even if you didn't list CJK code charts, you are still looking at a good 1500-2000 pages. Not that I don't have a vested interest in getting this to happen for future versions, but publishing Unicode in its entirety is an undertaking getting orders of magnitude more difficult to accomplish each year. Van
Re: Unicode Core
On 2012-06-21, Michael Everson ever...@evertype.com wrote: On 21 Jun 2012, at 09:47, Raymond Mercier wrote: While I am very glad to have this, I really do wonder why there was not a full publication of Unicode 6 or 6.1 from the corporation itself, with all the charts, as we have had with Unicode 1 to 5. Surely there is a market for this ? Perhaps less than us character mavens would imagine. Books don't publish themselves, and publishing takes resources of various kinds. Not much, if they use the Lulu route, as they already have an account set up. An hour of somebody's time should do it. And at a Lulu price, there'll be a lot more of a market than at an Addison-Wesley price! -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Unicode Core
Michael Everson: Perhaps less than us character mavens would imagine. Books don't publish themselves, and publishing takes resources of various kinds. Julian Bradfield: Not much, if they use the Lulu route, as they already have an account set up. An hour of somebody's time should do it. And at a Lulu price, there'll be a lot more of a market than at an Addison-Wesley price! I haven't work out the number of pages needed for all the charts, but even if it needed two volumes, what is the problem with that ? It is not just for private libraries like mine, but this is something, complete with the charts, that should be in the reference section of every university library, and every computer library. Or do we tell the library user that they can always download the charts ? Raymond Mercier
Re: Unicode Core
At the price of this lulu edition, I would have happily bought also an edition with charts and standard annexes, scaled proportionally. Would it be possible to know the sales figures of this edition? Only to understand if the effort for the pubblication has been worthwhile. And the sales figures of the previous versions? Cheers P.
Re: Unicode Core
On 21 Jun 2012, at 13:26, Pierpaolo Bernardi wrote: And the sales figures of the previous versions? Everybody, The Powers That Be are looking into it, and discussion on this list isn't going to provide new information unavailable to The Powers. Michael Everson * http://www.evertype.com/
Re: Unicode Core
On 6/21/2012 3:22 AM, Julian Bradfield wrote: Not much, if they use the Lulu route, as they already have an account set up. An hour of somebody's time should do it. And at a Lulu price, there'll be a lot more of a market than at an Addison-Wesley price! The Unicode Standard easily uses hundreds of fonts for the code charts, from a variety of sources. Despite what should theoretically work, not all systems can actually print every code chart. Some users cannot print certain of the existing PDFs on their systems, and POD providers have similar issues. The Unicode code charts provide a very nice stress test for some aspects of rendering, it turns out. So, as long as code charts create production issues, print-on-demand for them is effectively not feasible. The standard annexes exist in HTML format. For Unicode 5.0, I took the trouble to create a set of PDFs from them. At the time, they were printed with the core specification which meant, their overall quality and appearance had to at least resemble that of the rest of the book. So I ended up designing a style sheet and to also edit the entire set of them to the same copy-edit standard as the book. With help of a copy editor. The time required for that preparation was measured in weeks, not hours. Now, what if one dispensed with some of the niceties? Well, you still end up with HTML doing really poorly when it comes to page breaks - particularly for tables. So, the minimal effort required would still require some fiddling with the files to get the pages to break not too atrociously and particularly to have tables and images behave sensibly. That effort would be measured in days, not hours. So, as long as the UAXs are HTML, print-on-demand for them is effectively not feasible. That leaves the core of the standard. And that's where things stand. Without solving the corresponding technical challenges, either of these two parts of the standard cannot easily be made available in POD format. At this time these appear to be hard limitations, and ones not primarily subject to considerations of marketability. A./
