> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> What if we had a InsetParbox that contained an InsetParagragh
Allan> (or a list of them). The parbox example is similar to a table
Allan> cell or a minipage in that it is a paragraph with restrictions
Allan> on size and placement.
I
On Mon, 15 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
[...]
> Asger> Now, the good question is whether a paragraph should be an
> Asger> inset in itself. I don't know. Similar for the document:
> Asger> Should a document be an inse
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I have thought a bit about how our basic, fundamental document
Asger> text representation data structure should look like. My best
Asger> bet so far is this:
Asger> A document is a list of paragraphs. A paragraph is a li
> We already have the string implementation, LString in 1.1 is a
> standard string (infunctionality not in implementation), I only know
> of two major missing things: some funcs returning iterators return
> wrong value, and reverse iterators is missing.
Great. We don't need reverse iterators, IM
>> Asger Alstrup Nielsen writes:
>> After reading it, the idea makes indeed sense. But this means
>> that we will disallow all compilers where C++ string is not good
>> enough (gcc 2.7.x and even 2.8.x currently, not too mention
>> probably many proprietary compilers).
AAN> Maybe we
"Asger Alstrup Nielsen" <[EMAIL PROTECTED]> wrote:
> So, in conclusion, I think you mostly agree that the design is sound, and
> complete enough to support the needs for the Asian encodings?
Yes and thank you very much for the reply. I understand your points better:
> Notice that the main thin
> (All the math glyphs are part of Unicode.)
Sorry, this is not true. What I meant was that we can make sure all the needed
math glyphs are part of our Unicode encoding, using the private area.
Greets,
Asger
> Sorry, I have not read your document nor followed this thread, but I have
> a question: are the math encodings contempled in your scheme? I'm not sure
> if they are part of unicode but in the MathML page there are listed
> several encodings for symbols and Greek: http://www.w3.org/TR/REC-MathML/
Asger,
Sorry, I have not read your document nor followed this thread, but I have
a question: are the math encodings contempled in your scheme? I'm not sure
if they are part of unicode but in the MathML page there are listed
several encodings for symbols and Greek: http://www.w3.org/TR/REC-MathML/
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> No. T1 is an output encoding, that is the encoding of the font used
>> in the dvi file. This has nothing to do with the input encoding,
>> which is the encoding that LaTeX reads, in order to translate
>> internally to its own
> No. T1 is an output encoding, that is the encoding of the font used in
> the dvi file. This has nothing to do with the input encoding, which is
> the encoding that LaTeX reads, in order to translate internally to its
> own 7bit format.
>
> LaTeX will *never* have to read a file in T1 encoding.
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> T1 is the LaTeX encoding, except that the glyphs from A0-FF can
Asger> be represented as a single character. T1 corresponds closely
Asger> to what I think we export into LaTeX file in LyX v1.0, when the
Asger> encoding is
[T1 encoding]
> Except that there are a lot of characters and accents at the places
> where latin1 places control characters.
I suspect that those "control characters" are only used when fonts are encoded.
Can LaTeX accept a file with characters and accents at those control
characters?
> What do
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> After reading it, the idea makes indeed sense. But this means that
>> we will disallow all compilers where C++ string is not good enough
>> (gcc 2.7.x and even 2.8.x currently, not too mention probably many
>> proprietary compi
> After reading it, the idea makes indeed sense. But this means that we
> will disallow all compilers where C++ string is not good enough (gcc
> 2.7.x and even 2.8.x currently, not too mention probably many
> proprietary compilers).
Maybe we have to build our own standard string and wstring imple
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The proposal involves changing most of the current LString
Asger> instances to ordinary C++ strings! Read the document to learn
Asger> why I want to do this.
After reading it, the idea makes indeed sense. But this means t
> Why wait til friday? You can designate me now. Just tell me what to do!
You should get the Unicode Character database, and convert that into a C++
program that can return information about each glyph.
The Unicode database file is a text file with one line for each glyph. Each
line is divided
On Mon, Mar 08, 1999 at 09:52:48AM +0100, Asger Alstrup Nielsen wrote:
> > > On Thu, Mar 04, 1999 at 12:04:21AM +0100, Asger Alstrup Nielsen wrote:
>
> Thank you ;-)
>
> I hope everybody realizes that I really agree with Joacim, but just hate to
> admit it.
>
> > You've got 'merged words' enabl
On Mon, Mar 08, 1999 at 06:47:31AM +0900, [EMAIL PROTECTED] wrote:
[lots of above-my-head stuff snipped]
> > \begin_float footnote
> > \layout Standard
> >
> > The information needed for this are available in the Unicode glyph database
> > which can be found somewhere on the net, try www.unicode
> > In other words, the encoding of a document is a document level property,
> > not a paragraph level property.
>
> Agreed. The question is "Are we going to allow \include{}-ing
> buffers in other encodings than the parent?" LaTeX exports will
> be affected by this since the preamble writer
> I read at least part of the eleven (?) pages, and I found most of it
> very sensible.
I'd be very interested in hearing about the part that are not sensible.
Greets,
Asger
> > On Thu, Mar 04, 1999 at 12:04:21AM +0100, Asger Alstrup Nielsen wrote:
> > > After Joacim's angry and furious rant about the lack of design documents,
> > > I figured that I would humour him a bit and write 11 pages about the
> > > strings and encodings in the new kernel.
>
> Asger I find thi
"Asger Alstrup Nielsen" <[EMAIL PROTECTED]> wrote:
> After Joacim's angry and furious rant about the lack of design documents, I
> figured that I would humour him a bit and write 11 pages about the strings and
> encodings in the new kernel. This is thus an experiment to try to prove him
> wrong
On Sun, 7 Mar 1999, Amir Karger wrote:
> On Thu, Mar 04, 1999 at 12:04:21AM +0100, Asger Alstrup Nielsen wrote:
> > After Joacim's angry and furious rant about the lack of design documents, I
> > figured that I would humour him a bit and write 11 pages about the strings and
> > encodings in the n
> I would call it a Pyrrhic victory (but only because I'm trying to show off :)
> It's really too bad not to see people at least saying "this looks great!". I
> think Joacim is right that we need design discussions, but unfortunately it
> seems that Asger is right and noone wants to have them.
Ae
On Thu, Mar 04, 1999 at 12:04:21AM +0100, Asger Alstrup Nielsen wrote:
> After Joacim's angry and furious rant about the lack of design documents, I
> figured that I would humour him a bit and write 11 pages about the strings and
> encodings in the new kernel. This is thus an experiment to try to
Hi!
After Joacim's angry and furious rant about the lack of design documents, I
figured that I would humour him a bit and write 11 pages about the strings and
encodings in the new kernel. This is thus an experiment to try to prove him
wrong about the design documents. I hope that nobody will re
27 matches
Mail list logo
