Jump to content

Johnathan Hebert

Evernote Staff
  • Content Count

    212
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Johnathan Hebert

  1. Correct Correct We are working to make tables scroll sideways on all devices, but there will be a period where some devices will still have the existing, non-sideways-scrolling, tables behavior.
  2. Thanks for reporting this -- when the table was first displayed on the phone, the columns should have been correctly sized relative to one another, like they were on Windows, but the table total width should have matched the note width.
  3. You will not have to manually fix them -- unless you edited and saved the note while it was displaying the squished tables. And correct, the bug fix is that it should not happen to new or existing tables. (I'm not sure what you mean by "fixed tables")
  4. If you edited a note with squished tables on iOS, then it will not be fixed automatically. There are no other cases that I am aware of where the tables will not be fixed. If you have some notes with squished tables on 8.2.2, please send them to me or support, and I will take a look.
  5. Can you send me this ENEX? Also, "PC" means Evernote for Windows, correct? Or does it mean the web client on a Windows PC?
  6. Thanks for mentioning this. Can you provide an ENEX file where simplify formatting removes returns, or point me to another thread where you provided one? Also, can you clarify what you expect to happen when you choose "simplify formatting"? It is supposed to adjust the underlying HTML of the note in such a way that it makes it more predictable and well-behaved while editing. For some complex notes, it is difficult to simplify it in such a way that accomplishes both (1) the exact same rendered look and feel of the note and (2) a predictable and well-behaved editing experience. For example, if you copy the entire yahoo homepage or the ny times homepage and paste it into a note, it will have a quirky editing experience because of the heavy complexity of the underlying HTML. However, if you simplify it, it will be more well-behaved, but the look and feel of the note will have changed. In other words, are you expecting "simplify formatting" to have no effect at all on the way the note renders?
  7. I think this one has been there for a while -- can you confirm it did not exist in earlier versions? Also, I'm curious what context menu option you were planning to use on that email header?
  8. Thanks for finding this. I think it only happens when your mouse is over the image while you are typing, correct?
  9. You have to edit (but not necessarily sync) the note to persist the change.
  10. Oh I understand now. I will see if we can reproduce in the latest internal builds. If so, the fix will not be in 6.6 Beta 2, but the following Beta 3
  11. It is a display thing, unless you save and sync the note, then it will persist the problem. If you are still seeing this issue, please provide a sample ENEX file and we can determine what is going on and fix it. This is a very high priority issue and I am really interested in any examples that can be provided.
  12. Pete can you give some ENEX files so I can test? We should not be touching any tables in web clips, emails, and several other note characteristics that we check for.
  13. Thanks for the update. It sounds like a Postbox issue, but we'll continue to investigate on our end.
  14. I'm not sure if the ENEX file is blank when Postbox hands it to Evernote, or after, but I think it is possibly a Postbox bug.
  15. Can you clarify the difference in how these were created?
  16. Thanks for posting this. I will see if I can figure out what is going on.
  17. Hi @doonyakka The ENEX file is blank, so maybe Postbox is creating blank notes in some cases? What should be there? Here is the ENML from inside the file you submitted : <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE en-note SYSTEM "http://xml.evernote.com/pub/enml2.dtd"> <en-note> <div lang="x-unicode"/> </en-note>
  18. This is fixed in internal builds, but will not ship with the 6.11.1 release. It will ship in the next Mac release, whether it is another patch release or not. Thanks for helping us find and solve this issue. If you want a workaround for now, you can remove all spaces and newlines between a closing tag and an opening tag, and it should fix the issue... so something like : <table><thead><th>header...</th><th>....
  19. I have your ENEX file from support, and I am looking into it. Thanks.
  20. This should be fixed in the 8.2.2 Beta 2, which is available. If you have a sample ENEX file, I can verify that it is fixed for you, or fix any remaining issues that are causing it.
  21. Sometimes the fixes can be quick, so it is okay to expect that for certain issues. In this case, it was a bit of a trade at first. The issues you are reporting are indeed helping us make the product better. Sometimes an improvement in one area means a change (not necessarily a bug) in another area. In this case, we do want to preserve line heights, and use <div>s for paragraph blocks in ENML. The fix we have should accomplish both, and ultimately make the product better. Please continue to give feedback on issues. I would be happy to provide more technical details on the nature of the fixes.
  22. The table issues should be fixed in 8.2.2 Beta 2. Can you confirm? Please understand that if you edited, saved and sync'd a note that had "bad looking tables", it will not repair those notes. You will need to recover those from note history in order to see that the tables are no longer rendered poorly.
×
×
  • Create New...