On 2014-12-20 Sat 20:52, Eli Zaretskii wrote:
>> Date: Sat, 20 Dec 2014 19:58:05 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
>> 
>>  >> IIUC this contradicts an earlier observation by Titus that
>>  >>
>>  >>     if the buffer in the specified window is displayed in two frames,
>>  >>     the returned character width was always the one used in the current
>>  >>     frame which is not necessarily the character width in the specified
>>  >>     window (the window may be in the other frame).  This is a problem
>>  >>     because character width can be different, if the two frames use
>>  >>     different default fonts.
>>  >
>>  > I don't see any contradictions.  I said nothing about windows, only
>>  > about frames and buffers.
>> 
>> His last sentence says that the outcome is dependent on the frame.  So
>> it does not "replace" the original frame-specific face but "merge" the
>> frame and buffer specific faces.
>
> No.  When a buffer is displayed that has a face in its
> face-remapping-alist, every face in that alist is replaced by its
> remapped face.

Yes, that's technically correct.  However, a common use case of
face-remapping-alist is to merge a new attribute into the existing
definition of a face, e.g:

  ((default (:height 1.2) default))

Moreover, the default face seems to be a special case.  If you define
face-remapping-alist as following:

  ((default (:height 1.2)))

the height attribute is merged into the existing definition of the
default face.  What this means is that the faces used in a buffer will
typically (but not necessarily) depend on the default font and thus on
the frame in which the buffer is displayed.

  Titus