Subject: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 2 Mar 2021 17:29:06 +0000

Greetings,

HP Inc. is requesting the registration of additional keywords for the "media" attribute [STD92] for some standard sizes that aren't yet registered. Here is the registration template and the keywords to be added:

Attributes (attribute syntax)
  Keyword Attribute Value                                      Reference
  --------------------------------------------------------     --------------
media (type2 keyword | name(MAX))                              [RFC8011]
  na_arch-e1_32x40in                                           [HP20210302]
  na_super-c_18x24in                                           [HP20210302]
  na_super-d_24x36in                                           [HP20210302]
  oe_10x12_10x12in                                             [HP20210302]
  oe_10x15_10x15in                                             [HP20210302]
  oe_14x18_14x18in                                             [HP20210302]
  oe_16x20_16x20in                                             [HP20210302]
  oe_20x24_20x24in                                             [HP20210302]
  oe_22x28_22x28in                                             [HP20210302]
  oe_24x30_24x30in                                             [HP20210302]
  om_photo_300x400mm                                           [HP20210302]
  om_photo_300x450mm                                           [HP20210302]
  om_photo_350x460mm                                           [HP20210302]
  om_photo_400x600mm                                           [HP20210302]
  om_photo_500x760mm                                           [HP20210302]
  om_photo_600x900mm                                           [HP20210302]
media-supported (1setOf (type2 keyword | name(MAX)))           [RFC8011]
  < all name values >                                          [RFC8011]

Let me know if there are any issues.

Cheers,
Smith

/**
    Smith Kennedy
    HP Inc.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 2 Mar 2021 15:13:00 -0500

Smith,

At first blush I see some duplicated sizes from the registry:

    na_arch-c_18x24in
    na_arch-d_24x36in

and the MSN2 spec doesn't allow those...

Also, while I appreciate keeping the na_WIDTHxHEIGHT_WIDTHxHEIGHTin form for those dimensional sizes, if they are primarily for photo/art printing I'd like to see a 'photo' prefix in the name portion, e.g.:

    oe_photo-16x20_16x20in

Similarly, the om_photo sizes should include the dimensions if there is no corresponding well-known name:

    om_photo-300x400_300x400mm

> On Mar 2, 2021, at 12:29 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]> wrote:
> 
> Greetings,
>  
> HP Inc. is requesting the registration of additional keywords for the “media” attribute [STD92] for some standard sizes that aren’t yet registered. Here is the registration template and the keywords to be added:
>  

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 3 Mar 2021 18:10:42 +0000

Hi Mike,

From: Michael Sweet <[email-masked]>
Sent: Tuesday, March 2, 2021 1:13 PM
To: Kennedy, Smith (Wireless & IPP Standards) <[email-masked]>
Cc: PWG IPP Workgroup <[email-masked]>
Subject: Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute

Smith,

na_arch-c_18x24in
na_arch-d_24x36in

and the MSN2 spec doesn't allow those...
[Smith K.] I know we have in the past agreed to not register certain new media keywords because their dimensions were redundant with others already registered. The recent discussion about media “family” grouping has made me question that. (I’m also having a hard time finding the clauses in PWG 5101.1-2013 that mandates the “no size redundancy” restriction.)
If a Client were implemented to present supported media using a hierarchical system where families are grouped together (e.g. Architectural, Photo, etc.) and the Printer vendor wanted that Client to offer the user both an “Architectural C” in the Architectural family and a “Super C” in the Photo family, this would be impossible using only the “media-supported” attribute without the Client knowing a-priori that na_arch-c_18x24in should be shown in two different places and with two different strings (which the Client presumably provides since the Printer can only provide one localized string in its message catalog for a given keyword).
If the Client were implemented to use “media-col-database” rather than “media-supported”, the “media-key” value for the two variants could both use “na_arch-c_18x24in” and then I suppose the “Super C” could have some suffix on it (‘na_arch-c_18x24in_photo-super-c’) to make it unique, and that would then provide a unique key in the message catalog so it could have a different label. But we would still have no standard solution for the family problem, though.

oe_photo-16x20_16x20in

[Smith K.] I don’t have a problem with this recommendation in principle, but I’d like to see it codified in an update to MSN2. Seeking information on the “oe_10x12_10x12in” and such – more soon.

> On Mar 2, 2021, at 12:29 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]<mailto:[email-masked]>> wrote:
>
> Greetings,
>
> [email-masked]<mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp<https://www.pwg.org/mailman/listinfo/ipp>

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 3 Mar 2021 15:21:42 -0500

Smith,

> On Mar 3, 2021, at 1:10 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> 
> Hi Mike,
>  

Ugh, it looks like MSN 2 lost this text from MSN 1:

5.1.4 For interchange between programs, the dimensions presented in this standard must never be converted to the another system of units, but must remain as defined in this standard. Furthermore, an identical size shall never appear in this standard with different units. Programs may convert the dimensions to other units when displaying these names to human users and for internal use, both of which are outside the scope of this standard.

> If a Client were implemented to present supported media using a hierarchical system where families are grouped together (e.g. Architectural, Photo, etc.) and the Printer vendor wanted that Client t…

So three notes:

1. CUPS-based systems (including Linux, macOS, and iOS) never use any localized media size names from the Printer
2. Windows 10's IPP class driver only supports well-known media sizes at present (where "well known" seems to be limited to standard office printer sizes) - yes, I've filed a bug report on it...
3. macOS (at least) groups media sizes by dimension, for example "US Letter" and "US Letter (Borderless)" while iOS and CUPS clients do no grouping.

> If the Client were implemented to use “media-col-database” rather than “media-supported”, the “media-key” value for the two variants could both use “na_arch-c_18x24in”

"media-key" is a *unique* keyword for a combination of media-size, media-type, etc.  "media-name" (the localized name) might be the same but I don't see any Client using it since (as I've noted previously) current Clients use the dimensions to lookup the corresponding localized name (even if it is a dimensional name like "4 x 6")

> and then I suppose the “Super C” could have some suffix on it (‘na_arch-c_18x24in_photo-super-c’) to make it unique, and that would then provide a unique key in the message catalog so it could have a different label. But we would still have no standard solution for the family problem, though.
> 

It isn't super clear in MSN2, but section 5.1.5 says:

The common usage of some names can represent several physical sizes, e.g., folio, quarto, foolscap, and executive. To avoid naming and sizing conflicts, a hyphenated identifier MUST be used to link the names to a specific size.

and then we define multiple sizes using the name prefix "photo", "index", "govt", "fanfold", etc. with "-extra" and "-tab" suffixes for many sizes as well.

Like I said, if those dimensional sizes are more widely used then there is precedence (just look at MSN2) for registering purely dimensional names, but if all we cared about was the dimensions we'd just use the media-size collection in media-col...

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 3 Mar 2021 22:51:08 +0000

Hi Mike,

Sent: Wednesday, March 3, 2021 1:22 PM

Smith,

On Mar 3, 2021, at 1:10 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mike,

From: Michael Sweet <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 2, 2021 1:13 PM
To: Kennedy, Smith (Wireless & IPP Standards) <[email-masked]<mailto:[email-masked]>>
Cc: PWG IPP Workgroup <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute

Smith,

na_arch-c_18x24in
na_arch-d_24x36in

[Smith K.] I filed an errata: https://www.pwg.org/dynamo/issues.php?U106

So three notes:

[Smith K.] Understood. And it is up to the Client implementor to take advantage of message catalog provided strings or family information (or not). But there are other clients that do use the behavior I described, including HP vendor drivers for Windows and Android. We can do it with a vendor extension but I would prefer to not do that.

[Smith K.] I think we are talking about two different things: how the PWG has defined the members of the “media-col” collections to be used along with other facilities of IPP such as printer-resident message catalogs, and how some clients have been implemented to use those members and other IPP facilities. I don’t doubt your assertion that CUPS-based systems have been implemented to choose non-printer-resident strings based on “media-size” or “media-size-name” and ignore “media-key”. But is that how we in the PWG are intending “media-col-ready” and “media-col-database” to be used?

(I don’t see a “media-name” member registered with IANA or in 5100.7…)

oe_photo-16x20_16x20in

________________________
Michael Sweet

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 3 Mar 2021 18:08:46 -0500

Smith,

> On Mar 3, 2021, at 5:51 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> ...
> So three notes:
> 

If we are using media-col-database, I would rather have another member attribute that provides the grouping information because modern clients use media-col-database/ready and *not* media-supported/media-ready (in order to get supported media types, sources, and margins).

> [Smith K.] I think we are talking about two different things: how the PWG has defined the members of the “media-col” collections to be used along with other facilities of IPP such as printer-reside…

Yes.

The "media-size" member attribute is REQUIRED while "media-size-name" and "media-key" are just RECOMMENDED.  The whole purpose of MSN size names was to formalize the syntax of keyword names so they were self-describing with "natural" dimensions, so that the "media" attribute would only specify the desired media size (and not the type or source).  All legacy media values were deprecated with STD92, making media-col the only way to specify media size, type and source (via member attributes).

> (I don’t see a “media-name” member registered with IANA or in 5100.7…)

Sorry, "media-info" (RECOMMENDED).

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Wed, 10 Mar 2021 02:25:19 +0000

Hi Mike,

I'm going to get back to the new media keywords in a separate response, but it seems like there are some issues here that need resolution. More below

Smith

> On Mar 3, 2021, at 4:08 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

Agreed. So "media-family" (name(MAX)) or "media-group" (name(MAX))?

> The "media-size" member attribute is REQUIRED while "media-size-name" and "media-key" are just RECOMMENDED.

OK, and I don't dispute this.

But let's say that a Printer supports a number of standard media sizes, and the Printer's manufacturer wanted to support some vendor-unique media sizes, and provide localized labels / names for these. If the Printer only provided "media-size", like the example from page 43 of 5100.7-2019, what value from the media-col collection would a Client be expected to use as the key to locate the appropriate string in the message catalog?

media-col-database={
        /* Vendor size */
        media-size={
          x-dimension=22000
          y-dimension=22700
        }
        media-source='auto'
        media-type='stationery'
      }

It seems that the Printer would need to provide "media-size-name" or "media-key" if the string were to be acquired from the IPP Message Catalog, and could provide both. But which member would the Client be expected to use as its key? Should the Printer provide the same strings for both keys? It seems like 5100.7 needs some guidance on this. The "finishing-template" member of "finishings-col" is the obvious (and required) member for finishings, but we don't seem to have this for "media-col".

>  The whole purpose of MSN size names was to formalize the syntax of keyword names so they were self-describing with "natural" dimensions, so that the "media" attribute would only specify the desired media size (and not the type or source).  All legacy media values were deprecated with STD92, making media-col the only way to specify media size, type and source (via member attributes).

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 10 Mar 2021 10:01:02 -0500

Smith,

> On Mar 9, 2021, at 9:25 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
>> ...

I think "media-group" (or "media-category") since "family" would imply the sizes are marketed together (like a family or series of printers) vs. the desired grouping of sizes.  But I'd only want to add this if we had some idea that it would be supported by IPP Clients - otherwise why bother?

> But let's say that a Printer supports a number of standard media sizes, and the Printer's manufacturer wanted to support some vendor-unique media sizes, and provide localized labels / names for the…

You would localize the equivalent "media" keyword value, either from a "media-size-name" value or by looking up the printer's self-describing media size name (in media-supported) that corresponds to the dimensions of "media-size".

But like I said, no client that I am aware of uses the printer's strings file to lookup localized media names.

> ...
> It seems that the Printer would need to provide "media-size-name" or "media-key" if the string were to be acquired from the IPP Message Catalog, and could provide both.

media-key would allow for the combinations ("US Letter Borderless, Glossy Photo"), which a Client could lookup using the "media-key.value" string.

> But which member would the Client be expected to use as its key? Should the Printer provide the same strings for both keys? It seems like 5100.7 needs some guidance on this.

I didn't bother because Clients don't use the printer's strings file to localize media sizes.   This is because we've defined all of the common names that can be consistently localized for all printers by the client, have a common syntax that provides the dimensions, and because dimensional names provide the best user experience for uncommon sizes.  Common photo sizes are a case in point - who knows that 8R refers to an 8x10" photo size?

> The "finishing-template" member of "finishings-col" is the obvious (and required) member for finishings, but we don't seem to have this for "media-col".

Because for finishing-template there is no standard for how the keywords are formed (beyond the simple enum keyword values), making localization with the printer's strings file desirable/the easy way out (otherwise you need to parse out the member attributes and their values to determine what the template does...)

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Thu, 11 Mar 2021 19:23:01 +0000

Hi Mike,

Coming back to the registrations, for now HP Inc. would like to register these, with names structured as per your request:

Attributes (attribute syntax)
  Keyword Attribute Value                                      Reference
  --------------------------------------------------------     --------------
media (type2 keyword | name(MAX))                              [RFC8011]
  na_arch-e1_32x40in                                           [HP20210302]
  oe_photo-10x12_10x12in                                       [HP20210302]
  oe_photo-10x15_10x15in                                       [HP20210302]
  oe_photo-14x18_14x18in                                       [HP20210302]
  oe_photo-16x20_16x20in                                       [HP20210302]
  oe_photo-20x24_20x24in                                       [HP20210302]
  oe_photo-22x28_22x28in                                       [HP20210302]
  oe_photo-24x30_24x30in                                       [HP20210302]
  om_photo-300x400_300x400mm                                   [HP20210302]
  om_photo-300x450_300x450mm                                   [HP20210302]
  om_photo-350x460_350x460mm                                   [HP20210302]
  om_photo-400x600_400x600mm                                   [HP20210302]
  om_photo-500x760_500x760mm                                   [HP20210302]
  om_photo-600x900_600x900mm                                   [HP20210302]
media-supported (1setOf (type2 keyword | name(MAX)))           [RFC8011]
  < all name values >                                          [RFC8011]

We can perhaps discuss at today's IPP WG meeting if these are acceptable for registration.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Mar 2, 2021, at 1:13 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> ________________________
> Michael Sweet
> 
>

---

From: Christoph Päper via ipp <[email-masked]>
Date: Fri, 12 Mar 2021 08:38:55 +0100

Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]>:
>                         [HP20210302]

Metric photographic media are commonly referred to by centimeters:

om_photo-30x40_300x400mm 

etc.

---

From: Michael Sweet via ipp <[email-masked]>
Date: Sat, 13 Mar 2021 09:25:43 -0500

[Whew!]

All,

OK, so I've gone through ISO 1008.  The sizes there are based on the original inch measurements but are recorded in the standard as rounded millimeters, so 10x12 becomes 254x305mm vs. 254x304.8mm that an unrounded conversion would be.  Tolerances are +/-1 or 2 millimeters depending on the total length.  Given that the sizes were originally defined (and well known in) inches and the existing registered size names use the "oe" prefix and sizes in inches, I am inclined to use inches for the one ISO 1008 size (16R) that we've missed over the last 8 years since MSN2 was published rather than introduce a single ISO photo size name.

Here is a quick ASCII table of the standard numbered [0], ISO 1008, and ISO 1008-derived sizes.  I've included a notes column showing that we're previously registered other names for most of these sizes:

  Photo
  Name    Inches    Millimeters  Source         Notes
  ------  --------  -----------  -------------  --------------
  3R      3.5x5     89x127       ISO 1008       oe_photo-l_3x5x5in [1], "L" in Japan
  4R      4x6       102x152      Other          na_index-4x6_4x6in [1]
  A6                105x148      ISO 216+1008   iso_a6_105x148mm [1]
  5R      5x7       127x178      ISO 1008       na_index-5x7_5x7in [1] "2L" in Japan
  6R      6x8       152x203      Other          na_index-4x6-ext_6x8in [1], "8P" in Japan
  8R      8x10      203x254      ISO 1008       na_govt-letter_8x10in [1], "6P" in Japan
  S8R     8x12      203x305      Other          "6PW" in Japan
                    210x296      ISO 216+1008   iso_a4_210x197mm [1]
          8.5x11    216x279      ISO 1008       na_letter_8.5x11in [1]
          9.5x12    240x305      ISO 1008       na_letter-extra_9.5x12in [1]
  10R     10x12     254x305      ISO 1008       oe_photo-10r_10x12in [2]
  S10R    10x15     254x381      Other          oe_photo-s10r_10x15in [2]
  11R     11x14     279x356      ISO 1008       na_edp_11x14in [1]
  S11R    11x17     279x432      ANSI           na_ledger_12x17in [1]
  S12R    12x15     305x381      Other
          12x16     305x406      ISO 1008       oe_12x16_12x16in [2]
  S12R    12x18     305x457      Other          na_arch-b_12x18in [1]
  14R     14x17     356x431      Other          oe_14x17_14x17in [2]
          14x18     356x457      Other
  16R     16x20     406x508      ISO 1008       Approx. 40x50cm
  20R     20x24     508x610      ISO 1008       oe_photo-20r_20x24in [2], Approx. 50x60cm
  22R     22x29.5   508x749      Other
  24R     24x31     609x800      Other
  30R     30x40     762x1016     Other          May be confused with 30x40cm

  [0]: https://mainthebest.com/sizes/photo-print-sizes-r-series-sizes/
  [1]: https://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn20-20130328-5101.1.pdf
  [2]: https://ftp.pwg.org/pub/pwg/ipp/registrations/ippwg-media-size-20160229.txt

....

So, there are three sizes that HP has proposed that we have already registered (10x12, 10x15, 20x24) and a few standard photo sizes that were not included in HP's registration request.  This, combined with Christoph's observations about metric sizes yields the following updated registration:

Attributes (attribute syntax)
  Keyword Attribute Value                                      Reference
  --------------------------------------------------------     --------------
media (type2 keyword | name(MAX))                              [RFC8011]
  na_arch-e1_32x40in                                           [HP20210302]
  oe_photo-s8r_8x12in                                          [HP20210302] (added)
  oe_photo_s12r_12x15in                                        [HP20210302] (added)
  oe_photo-14x18_14x18in                                       [HP20210302]
  oe_photo-16r_16x20in                                         [HP20210302]
  oe_photo-22x28_22x28in                                       [HP20210302]
  oe_photo-22r_22x29.5in                                       [HP20210302] (added)
  oe_photo-24x30_24x30in                                       [HP20210302]
  oe_photo_24r_24x31in                                         [HP20210302] (added)
  oe_photo_30r_30x40in                                         [HP20210302] (added)
  om_photo-30x40_300x400mm                                     [HP20210302]
  om_photo-30x45_300x450mm                                     [HP20210302]
  om_photo-35x46_350x460mm                                     [HP20210302]
  om_photo-40x60_400x600mm                                     [HP20210302]
  om_photo-50x76_500x760mm                                     [HP20210302]
  om_photo-60x90_600x900mm                                     [HP20210302]

Thoughts?

> On Mar 11, 2021, at 2:23 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> 
> Hi Mike,
> 

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Thu, 18 Mar 2021 22:48:10 +0000

Hi Mike,

Waiting for final confirmation from colleagues but I think your final list is good. Thanks for doing the legwork, Mike! I was in the process of buying myself a copy of ISO 1008 (will still do that). So if no other changes, this would be the registration:

Attributes (attribute syntax)
  Keyword Attribute Value                                      Reference
  --------------------------------------------------------     --------------
media (type2 keyword | name(MAX))                              [RFC8011]
  na_arch-e1_32x40in                                           [HP20210302]
  oe_photo-s8r_8x12in                                          [HP20210302]
  oe_photo_s12r_12x15in                                        [HP20210302]
  oe_photo-14x18_14x18in                                       [HP20210302]
  oe_photo-16x20_16x20in                                       [HP20210302]
  oe_photo-22x28_22x28in                                       [HP20210302]
  oe_photo-22r_22x29.5in                                       [HP20210302]
  oe_photo-24x30_24x30in                                       [HP20210302]
  oe_photo_24r_24x31in                                         [HP20210302]
  oe_photo_30r_30x40in                                         [HP20210302]
  om_photo-30x40_300x400mm                                     [HP20210302]
  om_photo-30x45_300x450mm                                     [HP20210302]
  om_photo-35x46_350x460mm                                     [HP20210302]
  om_photo-40x60_400x600mm                                     [HP20210302]
  om_photo-50x76_500x760mm                                     [HP20210302]
  om_photo-60x90_600x900mm                                     [HP20210302]
media-supported (1setOf (type2 keyword | name(MAX)))           [RFC8011]
  < all name values >

And the reference date would likely be set to the date it was approved - hopefully next Thursday.

Smith

> On Mar 13, 2021, at 7:25 AM, Michael Sweet <[email-masked]> wrote:
> 
> [Whew!]
> 
> All,
> 
> [0]: https://mainthebest.com/sizes/photo-print-sizes-r-series-sizes/ <https://mainthebest.com/sizes/photo-print-sizes-r-series-sizes>
> [1]: https://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn20-20130328-5101.1.pdf <https://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn20-20130328-5101.1.pdf>
> [2]: https://ftp.pwg.org/pub/pwg/ipp/registrations/ippwg-media-size-20160229.txt <https://ftp.pwg.org/pub/pwg/ipp/registrations/ippwg-media-size-20160229.txt>
> 
> 
> ....
> 
> > On Mar 11, 2021, at 2:23 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi Mike,
> >

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 18 Mar 2021 19:40:36 -0400

Smith,

I think you missed one (see below).

> On Mar 18, 2021, at 6:48 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> 
> Hi Mike,
> 

________________________
Michael Sweet

---

From: Christoph Päper via ipp <[email-masked]>
Date: Fri, 19 Mar 2021 21:28:27 +0100

Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]>:
>  So if no other changes, this would be the registration:
> 

Isn’t “S12R” 12in by 18in (2:3), while 12in by 15in (3:4) is “12R”?

>   oe_photo-16x20_16x20in                                       [HP20210302]

As already noted, this would be “16R”.

>   oe_photo-22r_22x29.5in                                       [HP20210302]

One reference gave “22R” as 20in by 29.5in, which makes no sense. 

>   oe_photo_24r_24x31in                                         [HP20210302]

“24R” is elsewhere listed as 24in by 31.5in. 32in would make even more sense. 

>   om_photo-35x46_350x460mm                                     [HP20210302]

Is this the metric approximation of English 14x18 above? 

>   om_photo-50x76_500x760mm                                     [HP20210302]

I’ve checked some photo print services, they are offering a poster size of nominal 50cm by 75cm, but not 76cm.

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 19 Mar 2021 16:48:09 -0400

Christoph,

> On Mar 19, 2021, at 4:28 PM, Christoph Päper <[email-masked]> wrote:
> 

Yes, good catch.  This should be:

  oe_photo_12r_12x15in                                        [HP20210302]

> One reference gave “22R” as 20in by 29.5in, which makes no sense. 

Yes, the width is usually the number before the "R" (3R is the exception).

> “24R” is elsewhere listed as 24in by 31.5in. 32in would make even more sense. 

Both of the following sources list 24R as 24x31.5:

    https://en.wikipedia.org/wiki/Photo_print_sizes
    https://mainthebest.com/sizes/24r-sizes/

which would be 7.5 inches larger than the width (just like 22R), so this entry should be:

  oe_photo_24r_24x31.5in                                         [HP20210302]

Unfortunately, I'm having a hard time finding a definitive source for the larger "standard" sizes... :/

> Is this the metric approximation of English 14x18 above? 

Yes, several of these metric sizes are close to existing English sizes, but not exactly.

> I’ve checked some photo print services, they are offering a poster size of nominal 50cm by 75cm, but not 76cm. 

Let's see what Smith can find out from his end...

________________________
Michael Sweet

---

From: Christoph Päper via ipp <[email-masked]>
Date: Sat, 20 Mar 2021 08:21:51 +0100

Michael Sweet <[email-masked]>:
>> “24R” is elsewhere listed as 24in by 31.5in.
> 

Definitely don’t rely on Wikipedia in this case: I had updated that article after the other link had been presented here. That’s how I noticed the difference. 

> Unfortunately, I'm having a hard time finding a definitive source for the larger "standard" sizes... :/

Me too.