Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(parser/renderer/types): Support inline and image icons #613

Merged
merged 7 commits into from
Jun 16, 2020

Conversation

gdamore
Copy link
Collaborator

@gdamore gdamore commented Jun 15, 2020

This adds inline icon support, and significantly refactors the icon handling
to bring in support for image based icons and all of the icon attributes
supported by asciidoctor, bringing us to feature parity.

Additionally, we preserve some of the attributes from the font icon tags onto
images, allowing flip, rotate, and size styles to be applied to icons.
(This is an improvement over asciidoctor, and requires supporting CSS.)

One subtle difference when comparing output. We emit source paths for images
without a leading "./". That is because our use of path.Join() automatically
removes the redundant portion.

Fixes #587
Fixes #611
Fixes #610

gdamore added 2 commits June 15, 2020 11:11
This adds inline icon support, and significantly refactors the icon handling
to bring in support for image based icons and all of the icon attributes
supported by asciidoctor, bringing us to feature parity.

Additionally, we preserve some of the attributes from the font icon tags onto
images, allowing flip, rotate, and size styles to be applied to icons.
(This is an improvement over asciidoctor, and requires supporting CSS.)

One subtle difference when comparing output.  We emit source paths for images
without a leading "./".  That is because our use of path.Join() automatically
removes the redundant portion.

Fixes bytesparadise#587
Fixes bytesparadise#611
Fixes bytesparadise#610
Removed unused items, and consolidated down to just one icon type.
@codecov
Copy link

codecov bot commented Jun 15, 2020

Codecov Report

Merging #613 into master will increase coverage by 0.09%.
The diff coverage is 92.18%.

@@            Coverage Diff             @@
##           master     #613      +/-   ##
==========================================
+ Coverage   86.69%   86.78%   +0.09%     
==========================================
  Files          68       69       +1     
  Lines        4239     4322      +83     
==========================================
+ Hits         3675     3751      +76     
- Misses        360      363       +3     
- Partials      204      208       +4     

@gdamore gdamore added this to the v0.5.0 milestone Jun 15, 2020
Copy link
Member

@xcoulon xcoulon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! I just put some comments to ask you to add tests on other types of elements, to make sure that inline icons and images are properly parsed everywhere. But I believe that there's no need to verify all combinations of attributes again ;)

@@ -388,7 +388,8 @@ TitleElement <- element:(Word
/ Space+
/ CrossReference
/ InlinePassthrough
/ InlineImage
/ InlineIcon
/ InlineImage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a few tests just to make sure that inline icons/images can be parsed in title elements?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it turns out that we only render plain here. (Just like for images.) It's possible that this decision could be revisited. I think the ability to render images and icons inside a title could be useful. What will happen now is you'll get the Alt text.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I guess that only happens for section 1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, wait. I guess its for the table of contents only. Lol.

@@ -717,6 +718,7 @@ LabeledListItemTermElement <- element:(Word
/ ConcealedIndexTerm
/ IndexTerm
/ InlinePassthrough
/ InlineIcon
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a few tests just to make sure that inline icons/images can be parsed in labeled list terms?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm doing this .. so they only work in labeled list descriptions.

The grammar does not permit any markup in the terms. This should probably be considered a defect, but not one that I'm going to fix right now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(It's a preexisting defect.)

@@ -964,6 +967,7 @@ DoubleQuoteBoldTextElement <- Word
/ MonospaceText
/ SubscriptText
/ SuperscriptText
/ InlineIcon
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a few tests to verify that inline icons/images can be parsed in quoted text?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

pkg/renderer/sgml/html5/icon.go Show resolved Hide resolved
pkg/types/types.go Outdated Show resolved Hide resolved
pkg/types/types.go Outdated Show resolved Hide resolved
pkg/types/types.go Outdated Show resolved Hide resolved
pkg/types/types.go Outdated Show resolved Hide resolved
gdamore and others added 3 commits June 15, 2020 12:25
Co-authored-by: Xavier Coulon <[email protected]>
Co-authored-by: Xavier Coulon <[email protected]>
The definition lists and the ToC renderer didn't handle
icons properly.
})

It("inline icon in quoted text", func() {
source := `an _italicized icon:warning[] message_`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry to insist, but could you add a test for each kind of quoted text? (bold, monospace, etc.)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh. Ok. The parser tests are a royal pain. I have come to really despise the test framework -- it is almost impossible to read the output when there is an error sometimes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can try something like this:

ginkgo -focus "my test" pkg/parser -- -debug

with the -debug flag passed to the test, you'll have a dump of the actual result, so it's sometimes easier to compare with the expectation. Sometimes the diff is enough, but not always

@xcoulon
Copy link
Member

xcoulon commented Jun 16, 2020

This adds inline icon support, and significantly refactors the icon handling
to bring in support for image based icons and all of the icon attributes
supported by asciidoctor, bringing us to feature parity.

Additionally, we preserve some of the attributes from the font icon tags onto
images, allowing flip, rotate, and size styles to be applied to icons.
(This is an improvement over asciidoctor, and requires supporting CSS.)

One subtle difference when comparing output. We emit source paths for images
without a leading "./". That is because our use of path.Join() automatically
removes the redundant portion.

Fixes #587
Fixes #611
Fixes #610

next time let's try to have a single PR per issue, so it's easier to review. But I imagine that you found out the bugs while working on the PR and probably wanted to address them immediatley?

@gdamore
Copy link
Collaborator Author

gdamore commented Jun 16, 2020

Yes, it would have been a pain to do this in separate PRs, the fixes were not easily separable. I filed the tickets to log the issue, but splitting the work up not so easy.

@xcoulon
Copy link
Member

xcoulon commented Jun 16, 2020

Yes, it would have been a pain to do this in separate PRs, the fixes were not easily separable. I filed the tickets to log the issue, but splitting the work up not so easy.

sure, I understand the context here. It's just a good practice I want us to have here, to make PR focused and reviews simpler ;)

@xcoulon xcoulon merged commit fb7414e into bytesparadise:master Jun 16, 2020
@xcoulon
Copy link
Member

xcoulon commented Jun 16, 2020

thanks @gdamore 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

icon attribute support Support for image based icons Support inline icons
2 participants