Janus Bahs Jacquet
My feedback
-
8 votes3 comments · Adobe InDesign: Feature Requests » Document/Pages · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Janus Bahs Jacquet
supported this idea
·
-
21 votesJanus Bahs Jacquet
supported this idea
·
-
31 votesJanus Bahs Jacquet
supported this idea
·
-
27 votesJanus Bahs Jacquet
supported this idea
·
-
27 votes
An error occurred while saving the comment Janus Bahs Jacquet
commented
There isn’t even a need for such a complex table – nearly all fonts contain references to their weight according to the standard OS/2 classes (100–900). Just let us use those!
Similarly, nearly all fonts contain information as to whether they’re plain, oblique or italic. Just let us use those!
This is basically how it works with variable fonts, but there’s no reason it shouldn’t work with static fonts as well.
-
166 votes
An error occurred while saving the comment Janus Bahs Jacquet
commented
@Raphaël:
Using the OpenType All Small Caps is of course the correct way to go; but sometimes, you’re forced by circumstances outside your control to use fonts that do not support this feature and rely on special small-caps fonts, in which case text needs to be all-lowercase to give the same result.
Janus Bahs Jacquet
supported this idea
·
-
226 votes
Thanks for the suggestion. We have started to explore this feature. Will share more details soon
Thanks
AbhinavJanus Bahs Jacquet
supported this idea
·
-
17 votesJanus Bahs Jacquet
supported this idea
·
-
37 votesJanus Bahs Jacquet
supported this idea
·
-
453 votes
We have started to work on this feature. Will be sharing the beta builds soon. Please subscribe to InDesign CC Prerelease program (https://www.adobeprerelease.com/) to get access to beta builds
An error occurred while saving the comment Janus Bahs Jacquet
commented
@Dax Castro:
Hard disagree. InDesign is used for a lot more than just accessibility-optimised PDFs, and to deprive all users of vital features because they’re incompatible with a small subset of use cases is madness. Crucially, printed material does not need to comply with PDF/UA or WCAG 2.0/2.1, and printed material is – generally speaking – where this feature is needed the most. Tables are indeed for data, and there is absolutely NOTHING about the term ‘data’ that suggests it must visually fit neatly within the margins of a given page. Hacking your way around the problem by creating individual text frames and whatnots to mimic the look and functionality of a table is NOT “learning how to use the program properly”, but an ugly hack.
A popup such as you suggest would be a good idea, but it should appear when – and only IF – you export your document to a format that indicates adherence to accessibility standards. Anything else would be a UX nightmare no lesser than the accessibility.
-
9 votes
An error occurred while saving the comment Janus Bahs Jacquet
commented
This is absolutely vital for using tables. I cannot think of a single case where you would want cell borders to override table borders – if you wanted that, you’d simply just not specify a table border.
Table borders should override cell borders by default; anything else is just madness. The hierarchy should be table borders > header/footer cell borders > body cell borders, which is the exact opposite of what it currently is.
Janus Bahs Jacquet
supported this idea
·
-
1 vote0 comments · Adobe InDesign: Feature Requests » Layout/Graphics etc · Flag idea as inappropriate… · Admin →Janus Bahs Jacquet
shared this idea
·
-
300 votes46 comments · Adobe InDesign: Feature Requests » Long Document Features · Flag idea as inappropriate… · Admin →
We have added this feature in our backlog for future release
Janus Bahs Jacquet
supported this idea
·
-
33 votes16 comments · Adobe InDesign: Feature Requests » Document/Pages · Flag idea as inappropriate… · Admin →Janus Bahs Jacquet
supported this idea
·
How is this not a thing? Book syncing is about 60% useless when you have so little control over what gets synched.