Stephane Bortzmeyer wrote:
> On Fri, Jun 16, 2006 at 03:46:16PM -0700,
> Joe Touch <[EMAIL PROTECTED]> wrote
> a message of 85 lines which said:
>
>> - edit source code (argh - back to the stone age)
>
> I always assumed that most people involved in IETF edit source code
> daily (I did
On Fri, Jun 16, 2006 at 03:46:16PM -0700,
Joe Touch <[EMAIL PROTECTED]> wrote
a message of 85 lines which said:
> - edit source code (argh - back to the stone age)
I always assumed that most people involved in IETF edit source code
daily (I did not say "full-time", I said "at least daily
> From: Julian Reschke [mailto:[EMAIL PROTECTED]
> > XML2RFC once made me miss a draft deadline by choking on some XML I
> > wrote without saying why or where, leaving me with an impossible
> > debugging task. Formatting drafts in vi may take longer on average
> > than working with xml2rfc b
Iljitsch van Beijnum schrieb:
I think the mistake is to make the output format normative. If we make
the input format normative and publish that we're out of the woods:
obviously the input format is editable, and if it's sufficiently (but
not overly) well-defined output formats can be generated
On Jun 16, 2006, at 3:46 PM, Joe Touch wrote:
Forcing the input format means one of two things:
- edit source code (argh - back to the stone age)
I think we would generally get better results if Internet Standards
were authored by people who are comfortable editing source code.
Carl Malamud wrote:
This is not a job for a committee-of-the-whole ... I'd be
perfectly happy to let the IAB or IESG pick a religion and let
a working group define the rules of procedure. And, again,
piggybacking on the w3c religion seems like a really easy
way out of this never-ending debate.
Iljitsch van Beijnum wrote:
> On 17-jun-2006, at 0:18, Joe Touch wrote:
>
>> It's worth distinguishing the search for alternate normative output
>> formats from the search for a standard input format.
>
> I think the mistake is to make the output format normative. If we make
> the input format
Carl Malamud wrote:
>> It's worth distinguishing the search for alternate normative output
>> formats from the search for a standard input format.
>>
>> Or are you proposing 2629bis as a standard intermediate format, which
>> makes both camps (input and output) unhappy?
>
> I think we should pic
On 17-jun-2006, at 0:18, Joe Touch wrote:
It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.
I think the mistake is to make the output format normative. If we
make the input format normative and publish that we're out of t
> It's worth distinguishing the search for alternate normative output
> formats from the search for a standard input format.
>
> Or are you proposing 2629bis as a standard intermediate format, which
> makes both camps (input and output) unhappy?
I think we should pick one somewhat complete soluti
It's worth distinguishing the search for alternate normative output
formats from the search for a standard input format.
Or are you proposing 2629bis as a standard intermediate format, which
makes both camps (input and output) unhappy?
Joe
Carl Malamud wrote:
> Hi -
>
> There's been an awful lo
Hi -
There's been an awful lot of traffic on this subject, both this time
around and in the perpetual past. My $0.02 is that we're a standards
body and we shouldn't invent a new document profile/standard. That's
not our business, so we should steal code.
We have a home-grown effort done by a f
On 16-jun-2006, at 22:57, Ted Faber wrote:
SVG is currently exportable into most major bitmap formats.
http://librsvg.sourceforge.net/ the converter is rsvg. Runs out of
the
box on most free unices.
Of course, you can't go back from the bitmap to the vector, which is
exactly the point.
On Fri, Jun 16, 2006 at 10:24:26PM +0200, Iljitsch van Beijnum wrote:
> On 16-jun-2006, at 19:25, Lyndon Nerenberg wrote:
>
> >>As far as I know, support for SVG or _any_ vector image format is
> >>much, much less common than for bitmap formats such as PNG or GIF.
>
> >Yes, but SVG is catching
On 16-jun-2006, at 19:25, Lyndon Nerenberg wrote:
As far as I know, support for SVG or _any_ vector image format is
much, much less common than for bitmap formats such as PNG or GIF.
Yes, but SVG is catching up rapidly. As a W3C standard, it *will*
be widely implemented.
We'll have to wa
As far as I know, support for SVG or _any_ vector image format is much, much
less common than for bitmap formats such as PNG or GIF.
Yes, but SVG is catching up rapidly. As a W3C standard, it *will* be
widely implemented.
So editing bitmaps is
fairly trivial with well-defined results. Wit
On 16-jun-2006, at 10:41, Martin Duerst wrote:
But PNG should only be used for raster images, not for graphics.
SVG will provide the necessary scaling/positioning information for
embedded PNG images, so the device resolution concern is addressed.
As far as I know, support for SVG or _any_ vect
At 02:49 06/06/16, Lyndon Nerenberg wrote:
>> * Use of MHTML as the archive packaging.
>> * Use of XHTML 1.0 as the document encoding.
>> * Use of a standard IETF defined style sheet.
>> * Use of PNG encoding for all images.
>
>I'm in agreement with the first three, but I disagree with using PN
18 matches
Mail list logo
