unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* inter-client cut/copy paste & Small Caps
@ 2009-03-24  0:08 MON KEY
  2009-03-24  4:13 ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: MON KEY @ 2009-03-24  0:08 UTC (permalink / raw)
  To: emacs-devel

Can anyone confirm if inter-client copy paste will correctly
yank/insert Small Caps strings into an Emacs buffer from the
clipboard.  Is this even possible?  On emacsw32 when I yank in Small
Caps'd text from the clibboard I'm getting the text, but without the
caps properties.  Other w32 clients are correctly `interpreting' the
SmallCaps text and I'm unable to achieve reasonable translation on
emacs-w32.  I will check later this evening on a gnu/linux build if X
clients perform similarly.

While the case can be made that Small Caps are a typographical
convention the char translation I am currently getting is

"FAUX STRING OF SMALL CAPS" => "faux string of small caps"

I would expect a translation to:
"Faux String Of Small Caps"
or even;
"FAUX STRING OF SMALL CAPS"

i.e. something akin to `capitalize-region's or `upcase-region's
behaviour where Emacs can't reasonably interpolate the Small Caps
strings from the Clipboard contents.

Out of the box it doesn't appear that UTF-8 can even accommodate this
behavior in a reasonable way for the Latin scripts , i.e.
block U+1D00 - U+1D7F (Phonetic Extensions) provides _some_  Small
Caps encodings for 14 Latin Letters...

WTF? Obv. this isn't an Emacs problem per se but...

s_P




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inter-client cut/copy paste & Small Caps
  2009-03-24  0:08 inter-client cut/copy paste & Small Caps MON KEY
@ 2009-03-24  4:13 ` Eli Zaretskii
  2009-03-24 18:51   ` MON KEY
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2009-03-24  4:13 UTC (permalink / raw)
  To: MON KEY; +Cc: emacs-devel

> Date: Mon, 23 Mar 2009 20:08:55 -0400
> From: MON KEY <monkey@sandpframing.com>
> 
> Can anyone confirm if inter-client copy paste will correctly
> yank/insert Small Caps strings into an Emacs buffer from the
> clipboard.  Is this even possible?  On emacsw32 when I yank in Small
> Caps'd text from the clibboard I'm getting the text, but without the
> caps properties.  Other w32 clients are correctly `interpreting' the
> SmallCaps text and I'm unable to achieve reasonable translation on
> emacs-w32.

I'm guessing that you are copy/pasting Rich Text or some such.  Emacs
does not yet support these clipboard formats, it only supports (on
Windows) CF_UNICODETEXT, CF_TEXT, and CF_OEMTEXT clipboard data
types.  So what you get is the unformatted text variant of the
clipboard contents.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inter-client cut/copy paste & Small Caps
  2009-03-24  4:13 ` Eli Zaretskii
@ 2009-03-24 18:51   ` MON KEY
  2009-03-24 23:01     ` Miles Bader
  0 siblings, 1 reply; 4+ messages in thread
From: MON KEY @ 2009-03-24 18:51 UTC (permalink / raw)
  To: Eli Zaretskii, emacs-devel

> I'm guessing that you are copy/pasting Rich Text or some such.

Probably, but I tested the behavior last night at home with an
Emacs-pretest 23.91 build and got similar results.

> Emacs does not yet support these clipboard formats, it only supports (on
> Windows) CF_UNICODETEXT, CF_TEXT, and CF_OEMTEXT clipboard data
> types.  So what you get is the unformatted text variant of the
> clipboard contents.

The only available Unicode characters explicitly labeled `Small Caps'
are those of the IPA (International Phonetic Alphabet) - Unicode
Phonetic Extensions is block (1D00 - 1D7F).
See; (URL `http://www.unicode.org/charts/PDF/U1D00.pdf').

This is problematic because:
a) IPA is a phonetic notation - it doesn't *require* the rest of the
Latin Characters.

b) It is unlikely that this particular block will be extended to
accommodate `Small Caps' as it would create ambiguities counter to the
original intent of the IPA block.

c) Handling of RTF from the clipboard isn't the only issue/complication here.

Following is the generated source from the wikipedia entry on Small
Caps - (URL `http://en.wikipedia.org/wiki/Small_Caps'):

;; <p><a name="In_CSS" id="In_CSS"></a></p> <h2> <span class="editsection">
;; [<a href="/w/index.php?title=Small_caps&amp;action=edit&amp;section=2"
;; title="Edit section: In CSS">edit</a>] </span> <span class="mw-headline">In
;; CSS</span> </h2> <p>Small caps can be specified in <a href="/wiki/CSS"
;; title="CSS" class="mw-redirect">CSS</a> using "font-variant:
;; small-caps;". For example, the <a href="/wiki/HTML"
;; title="HTML">HTML</a></p><dl><dd><code>&lt;span style="font-variant:
;; small-caps;"&gt;Jane Doe&lt;/span&gt;</code></dd></dl><p>renders
;; as</p><dl><dd><span style="font-variant: small-caps;">Jane
;; Doe</span>.</dd></dl><p>Since the CSS styles the text, readers are still
;; able to copy the normally-capitalized plain text from the web page.</p>
;; <p><a name="In_CSS" id="In_CSS"></a></p> <h2><span class="editsection">[<a
;; href="/w/index.php?title=Small_caps&amp;action=edit&amp;section=2"
;; title="Edit section: In CSS">edit</a>]</span> <span class="mw-headline">In
;; CSS</span></h2> <p>Small caps can be specified in <a href="/wiki/CSS"
;; title="CSS" class="mw-redirect">CSS</a> using "font-variant:
;; small-caps;". For example, the <a href="/wiki/HTML"
;; title="HTML">HTML</a></p>

;; <dl> <dd><code>&lt;span style="font-variant: small-caps;"&gt;Jane
;; Doe&lt;/span&gt;</code></dd> </dl> <p>renders as</p> <dl> <dd><span
;; style="font-variant: small-caps;">Jane Doe</span>.</dd> </dl> <p>Since the
;; CSS styles the text, readers are still able to copy the
;; normally-capitalized plain text from the web page.</p>

How does Emacs accommodate a reasonably consistent and appropriate
rendered display of the CSS "span style-font-variant: small-caps;" in
the above example?   In this particular case I don't see an RTF/M$
transliteration issue but an Emacs' opportunity to DTRT (Display The
wRong Thing™).

Ignoring WYSIWYG editors (and their clipboard handling) this doesn't
change that utilization of Small Caps on the web is quite prevalent -
in many use cases the Small Caps  convey syntax. Simply discarding
this information is prob. not the best way to promote vigorous
utilization of 'The One True Editor'. It is worth noting that  Emacs
handles APL char data from the clipboard in a reasonable way. Is one
to assume that the relatively infrequently encountered APL syntax is
considered too significant to discard but it is OK for Small Caps to
be lossy?

Proposed explicit default UTF-8 Small-Caps substitutes:
Fullwidth Latin Letters - Halfwidth and Fullwidth Forms (FF00-FFEF)
Mathematical Alphanumeric Symbols - Mathematical Sans-Serif Capitals -
(1D5A0-1D5B9)

s_P

On Tue, Mar 24, 2009 at 12:13 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 23 Mar 2009 20:08:55 -0400
>> From: MON KEY <monkey@sandpframing.com>
>>
>> Can anyone confirm if inter-client copy paste will correctly
>> yank/insert Small Caps strings into an Emacs buffer from the
>> clipboard.  Is this even possible?  On emacsw32 when I yank in Small
>> Caps'd text from the clibboard I'm getting the text, but without the
>> caps properties.  Other w32 clients are correctly `interpreting' the
>> SmallCaps text and I'm unable to achieve reasonable translation on
>> emacs-w32.
>
> I'm guessing that you are copy/pasting Rich Text or some such.  Emacs
> does not yet support these clipboard formats, it only supports (on
> Windows) CF_UNICODETEXT, CF_TEXT, and CF_OEMTEXT clipboard data
> types.  So what you get is the unformatted text variant of the
> clipboard contents.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: inter-client cut/copy paste & Small Caps
  2009-03-24 18:51   ` MON KEY
@ 2009-03-24 23:01     ` Miles Bader
  0 siblings, 0 replies; 4+ messages in thread
From: Miles Bader @ 2009-03-24 23:01 UTC (permalink / raw)
  To: emacs-devel

MON KEY <monkey@sandpframing.com> writes:
> Ignoring WYSIWYG editors (and their clipboard handling) this doesn't
> change that utilization of Small Caps on the web is quite prevalent -
> in many use cases the Small Caps  convey syntax. Simply discarding
> this information is prob. not the best way to promote vigorous
> utilization of 'The One True Editor'. It is worth noting that  Emacs
> handles APL char data from the clipboard in a reasonable way. Is one
> to assume that the relatively infrequently encountered APL syntax is
> considered too significant to discard but it is OK for Small Caps to
> be lossy?

The "APL char data" is preserved because it's already "character level"
information, whereas the small caps info is higher-level formatting
info ("metadata").  They are very different things.

Because of that, there's precious little emacs could _do_ with higher
level formatting data, even if it preserved it -- you can't just insert
such formatted text into a plain text document and expect useful
results...

[I think in the vast majority of cases, small caps are used only for
presentation purposes anyway.]

-Miles

-- 
Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-03-24 23:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-24  0:08 inter-client cut/copy paste & Small Caps MON KEY
2009-03-24  4:13 ` Eli Zaretskii
2009-03-24 18:51   ` MON KEY
2009-03-24 23:01     ` Miles Bader

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).