https://bugzilla.wikimedia.org/show_bug.cgi?id=65945
--- Comment #16 from C. Scott Ananian <[email protected]> --- Ningauble: I've followed up on the wikiquote village pump with some more questions about wikiquote's use cases. Mar(c): Fixing 'upright' is the second part of this same RfC, so I don't recomment using 'upright=1' as a workaround. It's just pushing the problem down the road. The preferred workaround is to specify an explicit width if your page layout expects a constant width. (As you note, the 'square' image option proposed in the RfC was voted down in favor of making the "no explicit size" and "upright" options use a square bounding box. You are encouraged to read the transcript of the RfC discussions for more context.) Personally, the better long-term solution is providing better semantic markup for desired image size/layout, since the existing assumptions that images are a certain size/fixed width/etc are rather hostile to mobile and PDF/print rendering. I appreciate the constructive suggestions. The existing image option mechanism is baroque and confusing. I've fixed a number of bugs and corner cases already; I'm sorry that this one is causing more pain that previous ones. But hopefully we can find some solid ways to continue to improve and simplify image options. [FWIW, from my work on the LaTeX PDF backends (which render pages in double-column layouts), the most useful two semantic classes would be "single column image" (and image intended to fit in a single column, with height bounded to, say, 1/3 the page height and width bounded by the column width), and "full width image" (used for timelines, panoramic images, and certain diagrams) which are intended to span the full page. Using only these two semantic classes leads to pages which look consistent.] -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
