Jump to content
Due to limited holiday staffing, chat will be unavailable from Thursday, July 2 at 5:30 PM (CDT) to Monday, July 13 at 8 AM (CDT). This will allow us to reply to your email requests as quickly as possible. Thank you for understanding. ×

Johnathan Hebert

Evernote Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Johnathan Hebert

  1. Just want to provide an update here. I was able to discover a few bugs in the way we are rendering some notes based on the ticket you submitted. Looks like these problems were introduced with 6.10 or later, so that seems to align with what you are experiencing. We have prioritized the fixes for these issues and plan to have a solution very soon. I will try to make sure I update this thread when the fix is in place. The nature of the problem is that a few fixes to older problems are conflicting with the rendering of emails and web clips. A fix to prevent image skewing caused by very old versions of Evernote removes explicit heights on images, which will ensure a naturally correct aspect ratio for images that have an explicit width set. This will break the rendering of some web clips and emails that use image spacers and such because they attempt to intentionally skew image aspect ratios to achieve more complex layouts. There are a few other minor style rules that cause problems similar to this. Additionally, the postbox integration, while it is an email client, seems to add notes directly to the Evernote Mac desktop client using a client side API or something. This causes the note metadata to indicate that the source of the note was a desktop client, and not a note created via email. This further causes the note editor to prepare the note to be edited like a regular manually created note, instead of a web clip or email note. This breaks the layout. We are working on ways to fine-tune the detection of emails and web clips, even when the note metadata and/or third party client does not correctly identify them as such.
  2. Thanks for reporting this. I believe we have fixed this in internal builds. If you could export the note and provide the note ENEX to customer support, I will personally take a look at it and confirm that it is fixed.
  3. Looks like we are tentatively planning a 6.11.1, but I'm not certain yet. I manage the team the writes the rich text editor for all platforms, so I cannot say for sure when the Mac will ship. For the editor issues reported here, I can assure you we are focused on solving these as the highest priority.
  4. We're aiming to ship it in the next 6.11 follow-on update
  5. Hi, I have looked at the files you submitted, and have made notes on the ticket. Customer support should update you, and we will figure out what is going on. When I fully understand it, I will try to post a summary here for others.
  6. Thanks for the update. If you could provide some of those notes to support, I will take a look at them and try to diagnose the issue and schedule a fix as soon as possible.
  7. I understand those issues were reported, and the reason for those notes appearing that way seemed to have been fixed, at least in some cases here, There are several reasons the tables can be rendered that way, and having the note export would allow us to know for sure, but we did make a fix that looks for the note source to indicate it is a web clip or email, and then attempt to render it in its original form. However, even with that fix in place, some users will simply copy and paste an email, receipt or web clip into a note, and then the note source would unfortunately not identify it as a web clip or email. We are working on a fix to additionally recognize these pasted notes as web clips or emails when appropriate, and that should fix the problem for a majority of these cases. That fix should ship in the next update.
  8. There were problems with tables discovered in earlier betas, and although the symptoms are very similar -- "tables look wrong" -- the cause of those problems were fixed, but the underlying cause of the problems reported here is a different. I tried to clarify in my earlier comment, but if you believe the underlying cause is the same, please let me know.
  9. It looks like most of the issues are coming from tables that have been pasted in from emails or the web, but are not identified as such in the note metadata. We use clues in the note metadata to decide how to open notes and prepare them for editing, and will generally let web clips and emails render in their original form. However, these notes are not being recognized as web clips or emails, so go through different preparation steps in the editor, and that is causing the tables to render in a different way. Ideally it would be discovered in the beta, but in this case, the particular combination of this type of note metadata and the nested table structures from some emails was not encountered by any beta users. There was no change between the final beta and the final build that caused this issue. Any changes usually get another beta. In this case, I would expect those tables to have the same issue in the beta 4 build. It is a limited set of tables that are affected. It will most likely be tables from an email or a website that were pasted in (not clipped or emailed in), and contain tables within tables within tables, etc. We are working to treat these types of notes in the same way web clips and emails are treated, and that should fix the problem in the future. I'm happy to clarify any further technical details to explain what is going on with these notes.
  10. so then you will (incorrectly) end up with abcdef -- is that what you are saying?
  11. Thanks for bringing this up. This is by design in the case where the note ends with a table or a full width image, and maybe a few other cases. The intent is to make sure there is a way for you to move the cursor to the end of the note. We could look at different ways of solving this problem if it is causing other issues.
  12. Thanks for mentioning this -- can you post a screenshot? UPDATE: Nevermind, I see your screenshot above.
  13. @DTLow The tables should also be displayed at the correct width (as long as they were not edited and saved at the "skinny" width before), and the resize functionality should behave correctly. Can you confirm?
  14. Yes, the bug will only be saved if you make an edit o the note. We are fixing this and preventing it from happening in the first place.
  15. Thanks for the report, we have already fixed this in internal builds.
  16. Thanks for the details! We are aware of all of these, and they will all be fixed in the next release, with the exception of the 2x image size on paste, which may come in a follow up release. Please let us know if there are others, thank you!
  17. We are aware of this and it is fixed in internal builds, so you should see it fixed in the next release.
  18. Thanks for bringing this up. Can you mention a few of the "lots more bugs" you are seeing with the editor?
  • Create New...