Jump to content
We apologize for the inconvenience, but chat support is currently unavailable. Please feel free to submit an email ticket or reach out at discussion.evernote.com. Thank you for understanding. ×

Johnathan Hebert

Evernote Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Johnathan Hebert

  1. Hi Mike, There should be some additional improvements in the next 6.11.1 beta and GA. The reason for some of the changes to the formatting of pasted content was to improve the structure of the underlying HTML because it helps us make the editing experience more deterministic. The issues that we have fixed in these betas should retain the formatting of pasted content, but some long-standing editing issues may remain when working with that pasted content. We are working on a more complete solution that will allow pasted content to preserve its look and feel, while still improving the editing experience. If you are still having problems with particular types of content that is pasted in, please give me a few example ENEX files on this thread, or open a ticket with support and let me know, and I will look into it for you.
  2. Thanks, we are aware of this issue. However, I believe this has always been a bug in earlier versions of Evernote for Windows. Unfortunately, it is a bug with the embedded browser that we use to render the notes. We are working on a way to improve the drag/drop of content.
  3. How did you accomplish this? Did you export the ENEX file, modify the XML, then re-import it? How did you accomplish this? Can you be a bit more specific about where these settings were modified? No, I am looking at that template, and will let you know. This implies that you are manually editing the ENML in the notes -- is that correct? If so, then it is possible that some modifications to the ENML could be adjusted by the note editor when the note is loaded. The note editor will attempt to render the note in a way that preserves the look and feel of the note while adjusting the underlying ENML to make the editing more deterministic. If you, for example, manually changed the table ENML to have an explicit fixed width, then that could have made the table scrollable before version 8, but the note editor itself was not making those changes. This is absolutely the goal, accounting for different viewport sizes, resolutions, orientations, etc.
  4. I see, thank you for letting me know. I am the engineering manager for the team that builds the note editor, and the table rendering is something I can directly investigate for you. I can personally fix the bug or work with my team to fix the bug when we uncover the root cause. I do have an idea of what may be causing it, and I am working to get a fix out to you as soon as possible. Any ENEX files you could provide would of course be helpful, but no need to send sensitive data. If you could reproduce the issue with a sample note, that would also be helpful. I can also share some additional details on this issue that may be helpful. Some, but not all, of the "compressed tables" issues from the last release, 8.2, were fixed by this 8.2.1 release. However, there is more than one underlying cause of the "compressed tables" issue. The varying underlying causes of this problem are resulting in the same symptom -- namely "compressed tables" -- so it is difficult to distinguish them from one another. The issue that was fixed as a change in the stylesheet for the note editor that was intended to help make the tables horizontally scrollable in 8.2. That change was not necessary to make the tables horizontally scrollable, and was reverted for 8.2.1. Additionally, I believe the remaining problem is an issue where tables marked as '100%' width in the ENML document are being converted to '100px' width due to a bug introduced in the note editor. We do already have a fix for this remaining issue internally, and can be more confident in the fix with more real-world ENEX files. I am not certain when the fix will ship in the iOS app, but I can assure you we are working to get it fixed. If, after the fix is shipped, you still experience "compressed tables", it may be due to the fact that the '100px' width on your tables was saved back to the database. In that case, you can use the note history feature to recover an earlier version of your note (when the table was marked as '100%' width), and it should be back to normal. Please reach out directly to me if you need further clarification. We will get it fixed.
  5. Can you provide an ENEX file here or in a support ticket to demonstrate the problem? I have an idea of what the underlying cause is here, and I will look into it for you.
  6. Thanks for mentioning this, we have heard this from a few others. Can you provide an example ENEX file?
  7. Sure, please submit an ENEX file and we will take a look at what is causing this.
  8. Are you experiencing these problems with the current 6.11.1 Beta 1? Or are you talking about 6.11 GA? Also, can you describe the rendering errors in more detail? Or post a screenshot or sample ENEX file? I will take a look and see if we can fix the problem for you.
  9. Yes, sorry, it should be in both the next Mac and iOS minor version releases. Mac 6.12 and iOS 8.3
  10. We'll aim to fix this for the next Mac release, probably 6.12. I can share this forum post internally, and someone can reach out to you here if necessary.
  11. Other users have mentioned this -- we have fixed this internally and it should be working in 6.11.1. Please let us know if you still see the issue in the next release
  12. Thanks for letting us know. This will be fixed in the 2nd beta for Mac 6.11.1
  13. Yes, I see that on iOS you can put your cursor between the lines of text. The reason this is happening is because, since we do not have an option for line spacing in the editor, we are trying to preserve the visual gap between the lines by adding a blank line. The reason we do not leave the lines with a large vertical margin is because of changes in the editor to make it more deterministic to work with the underlying HTML. To be more specific, the notes are rendered in an embedded web view, and we use a feature of those web views that makes the content editable. That feature naturally works more predictably with "div" elements than "p" elements in the HTML. Your content consists of "p" elements, which receive a visual treatment in the editor that gives them vertical margins. Those lines are now represented as "div"s in the note editor, which allows us to work more deterministically with the content in the web view. Unfortunately, it is having the side effect of removing those vertical margins. We can address this in a few different ways, each of which have their pros and cons. I am discussing this with the team, and we are working on a solution.
  14. Thank you, this is helpful. If you could re-create this table (both the structure and style) in a future version of Evernote that allowed you to merge cells -- instead of nesting tables -- would that meet your needs? Why or why not?
  15. Howdy, I replied to the original forum post where you reported this issue. I will figure out what is going on in those notes....
  16. Hey there, this is definitely not by design. I am the engineering manager for the team that builds the note editor on all platforms, so I can figure this out for you. Could you provide an ENEX file or more details on how you created the note originally, and I will look into why this is happening.
  17. I saw the screenshots in your ticket, and asked CS to get some ENEX files and more info from you. I will take a look as soon as we get it. Thanks!
  18. As long as you do not edit the note in its ugly form, it will look fine in 6.11.1. However, if you do edit/save the note while it is looking bad, it will save the bad looking note to the database, and you will have to use the note history feature to recover an earlier version of the note.
  • Create New...