refactor: constraining alignment settings#125
Conversation
| throw new UnsupportedOperationException(MessageLocalization.getComposedMessage("dimensions.of.a.cell.are.attributed.automagically.see.the.faq")); | ||
| } | ||
|
|
||
| @Override |
There was a problem hiding this comment.
Can you add JavaDoc to this and any other new methods?
There was a problem hiding this comment.
I have not added Javadoc here because it's an implementation of interface method which is documented. I can add @inheritDoc, I guess. What do you think?
| } | ||
|
|
||
| @Override | ||
| public void setHorizontalAlignment(final HorizontalAlignment alignment) { |
|
Thanks for this contribution to the project. I have just looked briefly at the pull-request so far. Does this change in any possible way change the API, layout or behaviour for existing users of OpenPDF? If you have time, could you please also add a simple test-case to this pull-request? |
|
@daviddurand What do you think of this change? |
@andreasrosdal |
Guess I can, so I'll try |
|
Added very basic test case that setting alignment through new methods will set an underlying |
|
Thanks. Can you add license headers like in the other source code files? |
2 participants
Current API for vertical/horizontal alignment setting for table elements is not constrained at all, leading to errors. Also, in absence of documentation, it's not obvious (for me, actually) how to set alignment properly.
PR introduces enum types for available alignment modes as well as its application to table element classes