Viewport in decimals generating ERROR

[nekennedy]

<meta name="viewport" content="width=1007.9999999999999, height=1360.8" />

ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "width" value must be a positive number or the keyword "device-width"
ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "height" value must be a positive number or the keyword "device-height"

For the above viewport declaration in the HTML, I'm getting the below ERROR messages from epubcheck 5.0.0 (this file does not generate an error in epubcheck 4.2.6).

This affects very few of our files (2 out of 4000 FXL files tested) and in my personal opinion, it seems a bit weird to have a viewport in decimals like that. I'd be OK adjusting the error messaging to say whole numbers instead of fixing epubcheck to use floats BUT I'm not the right person to make that call!

[clapierre]

Hi Naomi, simple solution stop making Fixed layout books 😝 Sorry had to take a jab. Sure there is some bug. Thanks Charles EOM From: Naomi Kennedy ***@***.***> Date: Wednesday, January 25, 2023 at 9:25 AM To: w3c/epubcheck ***@***.***> Cc: Subscribed ***@***.***> Subject: [w3c/epubcheck] Viewport in decimals generating ERROR (Issue #1481) <meta name="viewport" content="width=1007.9999999999999, height=1360.8" /> ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "width" value must be a positive number or the keyword "device-width" ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "height" value must be a positive number or the keyword "device-height" For the above viewport declaration in the HTML, I'm getting the below ERROR messages from epubcheck 5.0.0 (this file does not generate an error in epubcheck 4.2.6). This affects very few of our files (2 out of 4000 FXL files tested) and in my personal opinion, it seems a bit weird to have a viewport in decimals like that. I'd be OK adjusting the error messaging to say whole numbers instead of fixing epubcheck to use floats BUT I'm not the right person to make that call! — Reply to this email directly, view it on GitHub<#1481>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB3A3LM52LQAA5HEYT2FXQLWUFOXFANCNFSM6AAAAAAUGSXL3M>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[prithiviclteam]

<meta name="viewport" content="width=1007.9999999999999, height=1360.8" />

ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "width" value must be a positive number or the keyword "device-width"
ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "height" value must be a positive number or the keyword "device-height"

For the above viewport declaration in the HTML, I'm getting the below ERROR messages from epubcheck 5.0.0 (this file does not generate an error in epubcheck 4.2.6).

This affects very few of our files (2 out of 4000 FXL files tested) and in my personal opinion, it seems a bit weird to have a viewport in decimals like that. I'd be OK adjusting the error messaging to say whole numbers instead of fixing epubcheck to use floats BUT I'm not the right person to make that call!

Hi Naomi, simple solution stop making Fixed layout books 😝 Sorry had to take a jab. Sure there is some bug. Thanks Charles EOM From: Naomi Kennedy @.> Date: Wednesday, January 25, 2023 at 9:25 AM To: w3c/epubcheck @.> Cc: Subscribed @.> Subject: [w3c/epubcheck] Viewport in decimals generating ERROR (Issue #1481) ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "width" value must be a positive number or the keyword "device-width" ERROR(HTM_057): [path to epub]/OEBPS/section_1.xhtml(199,79): Viewport "height" value must be a positive number or the keyword "device-height" For the above viewport declaration in the HTML, I'm getting the below ERROR messages from epubcheck 5.0.0 (this file does not generate an error in epubcheck 4.2.6). This affects very few of our files (2 out of 4000 FXL files tested) and in my personal opinion, it seems a bit weird to have a viewport in decimals like that. I'd be OK adjusting the error messaging to say whole numbers instead of fixing epubcheck to use floats BUT I'm not the right person to make that call! — Reply to this email directly, view it on GitHub<#1481>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB3A3LM52LQAA5HEYT2FXQLWUFOXFANCNFSM6AAAAAAUGSXL3M. You are receiving this because you are subscribed to this thread.Message ID: @.>

@nekennedy : Yes, same we processed out of more than 500+ titles using the same viewport. I have no idea why the epub checker generated this error. So, waiting for updated EPUBChecker version with remove this error..

[rdeltour]

it seems a bit weird to have a viewport in decimals like that. I'd be OK adjusting the error messaging to say whole numbers instead of fixing epubcheck to use floats BUT I'm not the right person to make that call

Good catch, and yeah I would expect an integer there, but the spec only says it must be a "positive number".

MDN says it's a number of pixel, while the current CSS Viewport draft, based on the old Apple parsing algorithm, tries to convert the string value using strtod so it would accept floats. Any thoughts @mattgarrish?

[mattgarrish]

Makes me wonder if they converted from some other unit to pixels. That'd be the only explanation I can think of for that kind of precision.

Would probably help to know what reading systems will do with decimal values, but seems harmless to allow even if we don't promote the practice.

Any thoughts on whether we should allow decimal values for the height/width viewport specifications @danielweck @bduga @wareid @larscwallin @davemanhall ?

[davemanhall]

@mattgarrish - in the reading system, looks like we treat as an integer and parse as follows:

typedef struct {
int height;
int width;
} Dimensions;

"width=900.25, height=600.75"
Printing description of size:
(Dimensions) size = (height = 600, width = 900)

I'll have to ask about the backend systems...

[danielweck]

Hello all, I just looked at Thorium's source code, I haven't run actual tests. The implementation expects integers but the parser shouldn't crash as we ignore the fractional part of the number (essentially, this is equivalent to a mathematical floor operation on the floating point value).