[TextShare] - proposal to make a desktop-wide format for text
Shaun McCance
shaunm at gnome.org
Thu Jun 19 13:48:32 PDT 2008
On Thu, 2008-06-19 at 21:59 +0200, François Revol wrote:
> > > Well, other candidates could be possible, like PDF, but it doesn't
> > > maintain a real logical sturcture AFAIK.
> >
> > In my experience, pasting formatted text seems to
> > work reasonably well. Granted, I don't do a lot
> > of word processing, so my experience is generally
> > limited to copying from a web browser into an IM
> > window.
>
> I already had issues copying text from a browser window to a text form
> in another window... it embedded links without showing, so I ended up
> posting <a href="foo"><a href="bar>...
What application were you pasting into? I just
copied some formatted text from Epiphany, then
pasted it into both gedit and Pidgin. In gedit,
I just got a plain-text version; in Pidgin I got
formatted text.
I strongly suspect that your browser offers a plain
text target. The application you pasted into must
have selected HTML, even though it doesn't really
understand it. (Some might consider this a feature
in, e.g., a text editor, where you might be editing
HTML source.)
> > I very much doubt either application implements
> > OpenDocument, and I doubt the developers are keen
> > on doing that. I have to assume it's HTML, which
> > seems to me like the most obvious cross-application
> > rich text format.
>
> It seems the most common, but not every app will want to have an html
> or xml parser just for pasting...
>
> OTH, if the toolkit itself provided the abstraction...
Well, you need a parser one way or another. It seems
more likely that an XML parser will already be loaded
than, say, an RTF parser. And ODF leaves you needing
an XML parser anyway, so (X)HTML is certainly no worse.
For simple stuff, GTK+ applications could probably just
use GMarkup without much effort. But we'd never reach
the uptake of HTML, so I don't think it's worth it.
> > > > copying a selection in a browser, including images.
> > >
> > > Indeed html doesn't embed images...
> >
> > I think the URL is probably sufficient for most
> > applications. Otherwise, HTML can embed images
> > using the data: URI scheme:
> >
> > http://en.wikipedia.org/wiki/Data:_URI_scheme
>
> Ah yes, that one, but it shouldn't be used for big stuff, it might
> overflow buffers.
I suppose it might, in poorly written applications.
Applications like Gnumeric and the GIMP put massive
amounts of stuff on the clipboard as it is. When
you have a lot of data, you've just got to accept
that big stuff is on the clipboard.
Anyway, any format the does embed images still has
to put all the image data there. Even if that format
can offer the images in binary, text encoding adds
what, 30%? A big image is big whether or not it gets
encoded with base64.
--
Shaun
More information about the xdg
mailing list